Semantic  Analyses  for  Storage  Management  Optimizations 
in  Functional  Language  Implementations 


by 


Young  Gil  Park 


A  dissertation  submitted  in  partial  fulfillment 
of  the  requirements  for  the  degree  of 
Doctor  of  Philosophy 
Department  of  Computer  Science 
New  York  University 
September  1991 


Approved  : 


Benjamin  Goldberg 
Research  Advisor 


©Young  Gil  Park 
All  Rights  Reserved.  1991 


To 

Grace  Sunjung  and  Jihwa  Park 


1 


Acknowledgements 


First,  I  would  like  to  express  my  sincere  thanks  to  my  advisor,  Professor  Benjamin 
Goldberg,  for  all  his  guidance,  suggestions,  advice  and  the  many  other  things  throughout 
the  years.  1  would  also  like  to  thank  Professors  Robert  Paige  and  Edmond  Schonberg  for 
reading  a  draft  of  this  thesis  and  giving  valuable  comments  as  well  as  serving  on  my  thesis 
committee.  1  wish  to  thank  all  the  other  members  of  my  committee,  Professors  Robert 
Dewar  and  Malcolm  Harrison,  for  their  helpful  comments  and  encouragements. 

For  their  advice  and  help,  1  am  grateful  to  all  the  people  in  Programming  Languages 
Lab  at  Courant  Institute,  Professors  Paul  Hudak  at  Yale  University,  Arvind  at  MIT,  Peter 
Lee  at  Carnegie- Mellon  University  and  Dr.  Henry  Baker  at  Nimble  Computer  Corporation. 

Last,  by  no  means  least,  1  would  like  to  thank  my  wife  Jihwa  and  my  daughter  Grace 
Sunjung  -  1  owe  everything  to  you!  1  would  also  like  to  thank  my  parent  for  their  constant 
love  and  support. 

This  research  was  supported  in  part  by  Korea  Government  Graduate  Fellowship,  Na¬ 
tional  Science  Foundation  (#CCR-8909634)  and  DARPA/ONR  (#N00014-90-1110). 


Abstract 


Semantic  Analyses  for  Storage  Management  Optimizations 
in  Functional  Language  Implementations 

Young  Gil  Park 

Pli.D.,  Department  of  Computer  Science,  New  York  University,  September  1991. 
(Research  advisor:  Benjamin  Goldberg) 


One  of  the  major  overheads  in  implementing  functional  languages  is  the  storage  manage¬ 
ment  overhead  due  to  dynamic  allocation  and  automatic  reclamation  of  indefinite- extent 
storage.  This  dissertation  investigates  the  problems  of  statically  inferring  lifetime  informa¬ 
tion  about  dynamically-allocated  objects  in  higher-order  polymorphic  functional  languages, 
both  strict  and  non-strict ,  and  of  applying  that  information  to  reduce  the  storage  manage¬ 
ment  overhead. 

We  have  developed  a  set  of  compile-time  semantic  analyses  for  a  higher-order,  monomor- 
phic,  strict  functional  language  based  on  denotational  semantics  and  abstract  interpreta¬ 
tion.  They  are  1)  escape  analysis ,  which  provides  information  about  the  relative  lifetimes 
of  objects  such  as  arguments  and  local  objects  defined  within  a  function  with  respect  to  an 
activation  of  the  function  call,  2)  refined  escape  analysis  which,  as  a  refinement  of  escape 
analysis,  provides  information  about  the  lifetimes  of  components  of  aggregate  structures, 
and  3)  reference  escape  analysis  which  provides  information  about  the  relative  lifetimes  of 
references  created  within  a  function  with  respect  to  an  activation  of  the  function. 

We  also  have  developed  a  compile-time  semantic  analysis  called  order- of- demand  anal¬ 
ysis  for  higher-order,  monomorphic,  non-strict  functional  languages,  which  provides  infor¬ 
mation  about  the  order  in  which  the  values  of  bound  variables  are  demanded  and  thus 
allows  one  to  compute  a  range  of  information  including  strictness,  evaluation-order,  and 
evaluation- status  information. 

Using  the  notion  of  polymorphic  invariance ,  we  describe  a  method  for  analyzing  a  poly¬ 
morphic  language  by  using  the  analyses  for  a  monomorphic  language.  We  then  extend  those 
analyses  for  a  strict  language  to  a  non-strict  language  using  non-strict  program  transfor¬ 
mation  and  evaluation-status  information. 


Based  on  statically  inferred  escape  information,  we  propose  a  combination  of  storage 
management  optimization  techniques  including  stack  allocation,  explicit  reclamation,  in- 
place  reuse,  reference  counting  elimination,  block  allocation/reclamation,  and  improving 
generational  garbage  collection. 
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Chapter  1 


Introduction 


Functional  programming  languages  provide  a  variety  of  useful  features  such  as  referential 
transparency,  higher-order  functions,  non-strict  semantics  and  implicit  storage  manage¬ 
ment.  Functional  languages,  however,  have  gained  popularity  much  slower  than  imperative 
ones  because  their  implementations  on  conventional  sequential  and  parallel  computers  have 
tended  to  show  relatively  poor  performance.  Optimization  to  improve  the  performance  of 
functional  languages  is  thus  an  essential  component  in  any  viable  implementation.  One  of 
the  major  overheads  incurred  by  functional  language  implementations  is  the  storage  man¬ 
agement  overhead  due  to  dynamic  allocation  and  automatic  reclamation  of  indefinite- extent 
storage.  This  thesis  explores  the  optimization  problem  of  reducing  the  storage  manage¬ 
ment  overhead  by  obtaining  lifetime  information  about  dynamically- allocated  objects  in 
higher-order  polymorphic  functional  languages,  which  is  inferred  at  compile-time  through 
semantics-based  analyses  of  high-level  source  programs. 

1.1  Functional  Languages 

The  class  of  modern  functional  programming  languages  exhibits  several  useful  features  as 
follows  ([7],  [31],  [40],  [66]): 

•  Referential  Transparency  (Equational  Reasoning)  :  In  pure  functional  programming, 
a  program  has  no  modifiable  state,  because  of  the  lack  of  an  assignment  operator,  and 
thus  is  made  up  entirely  of  expressions.  The  evaluation  of  an  expression  is  guaranteed 
to  have  no  other  effects  on  the  program,  that  is,  no  side-effects.  The  absence  of  side- 
effects  guarantees  the  mathematical  property  of  referential  transparency  which  means 
that  any  syntactically  identical  pair  of  expressions  are  semantically  the  same,  scope 
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rules  allowing,  and  this  makes  functional  programs  easier  to  reason  about.  Programs 
can  be  treated  as  a  system  of  equations  and  equational  reasoning  can  be  applied. 
Functional  languages  also  have  a  completeness  property  which  states  that  the  reduction 
of  an  expression  using  a  general  normal-order  strategy  is  guaranteed  to  yield  a  result 
if  a  result  is  mathematically  deducible. 

•  Higher-Order  Functions  :  The  notion  of  a  function  is  the  primary  abstraction  mecha¬ 
nism  in  any  programming  language  and  thus  facilitating  the  use  of  functions  increases 
the  utility  of  that  kind  of  abstraction.  Much  of  the  power  of  a  programming  lan¬ 
guage  can  come  from  the  advanced  use  of  functions.  Imperative  languages  such  as 
Algol68,  Pascal  and  C  allow  procedures  or  functions  to  be  passed  as  parameters  to 
other  procedures  and  functions,  but  does  not  permit  function- valued  or  procedure- 
valued  functions.  In  functional  languages,  functions  are  treated  as  first-class  objects 
like  any  other  data  object  in  the  language.  Functions  that  are  allowed  to  be  put  in 
data  structures,  passed  as  an  argument  in  function  calls,  and  returned  as  values  from 
expressions  including  function  calls  are  called  first-class  functions.  Those  languages 
supporting  higher-order  functions  generally  allow  functions  to  be  curried  or  partially 
applicable.  If  a  function  is  defined  to  take  several  arguments,  it  can  be  considered  as 
a  function  that  takes  only  one  argument  and  returns  a  curried  function. 

•  Non-strict  Semantics  :  The  reduction  of  a  function  application  in  a  language  can 
generally  be  performed  in  two  ways:  strict  (applicative-order)  evaluation  order  and 
non-strict  (normal-order)  evaluation.  In  strict  semantics ,  the  application  of  a  function 
to  its  arguments  results  in  the  arguments  being  evaluated  before  they  are  passed  to 
the  function  and  before  the  body  of  the  function  begins  execution.  This  corresponds 
to  applicative-order  reduction  in  the  lambda  calculus.  The  advantage  of  this  scheme, 
known  as  call-by-value ,  is  that  it  is  easy  to  implement  efficiently;  first  we  evaluate  the 
arguments,  then  we  call  the  function.  However,  it  may  result  in  unnecessary  evaluation 
if  an  argument’s  value  is  not  ultimately  required  by  the  called  function.  In  non- 
strict  semantics ,  an  argument  is  not  evaluated  unless  and  until  its  value  is  demanded 
inside  the  body  of  the  called  function;  all  arguments  are  passed  to  the  function  in 
an  unevaluated  form  and  are  only  evaluated  when  needed  inside  the  function  body. 
This  corresponds  to  normal-order  reduction  in  the  lambda  calculus.  The  advantage 
of  this  evaluation  method,  also  known  as  call-by-name,  is  that  no  effort  will  have 
been  wasted  if  the  argument  value  is  not  ultimately  required.  A  non-strict  semantics 
also  has  the  advantage  of  resulting  in  program  termination  more  often  than  a  strict 
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semantics  since  the  evaluation  of  a  non- terminating  expression  may  be  avoided.  If  a 
program  terminates  using  both  call-by- value  and  call-by  name,  then  the  same  result 
will  be  returned  in  both  cases,  which  is  guaranteed  by  the  Church-Rosser  Property. 
Thus,  the  non-strict  language  avoids  redundant  evaluations  and  is  more  expressive 
than  the  strict  language.  That  is,  it  increases  the  power  of  functional  abstraction  and 
allows  the  definition  of  infinite  structures. 

•  Implicit  Storage  Management  :  Another  major  feature  of  functional  languages  is  that 
there  is  no  notion  of  explicit  storage  management.  The  programmer  is  relieved  from 
having  to  think  about  how  or  where  the  data  objects  in  a  program  are  stored  within 
the  computer  memory  and  from  writing  code  to  recover  inaccessible  memory  and 
reuse  it.  This  is  an  important  abstraction  from  the  housekeeping  needed  with  com¬ 
mon  imperative  languages.  Data  types  can  be  defined  at  an  abstract  level  with  no 
concern  as  to  how  they  are  represented  internally,  this  being  handled  automatically 
by  implementation.  Furthermore,  the  lifetime  of  the  object  is  also  unimportant  as 
far  as  the  programmer  is  concerned  and  so  we  do  not  have  to  worry  about  when 
an  object  ceases  to  be  required  by  the  program.  Built-in  operations  on  data  auto¬ 
matically  allocate  storage  as  needed  and  storage  that  becomes  inaccessible  is  then 
implicitly  deallocated  by  triggering  garbage  collection.  The  absence  of  explicit  code 
for  managing  storage  effectively  for  data  objects  makes  programs  simpler  and  shorter. 

•  Static  (Implicit)  Polymorphic  Typing  :  A  type  system  for  a  language  is  a  set  of  rules 
for  associating  a  type  with  expressions  in  the  language  to  avoid  embarrassing  questions 
about  representations,  and  to  forbid  situations  in  which  these  questions  might  come 
up.  Most  modern  functional  languages  adopt  a  rich  static  strong  polymorphic  type 
system  ([19],  [27],  [60],  [69])  in  which  polymorphism  is  allowed  in  both  primitive  and 
user-defined  functions,  and  a  type  inference  system  can  be  used  to  infer  the  types 
of  expressions  when  little  or  no  type  information  is  given  explicitly.  Static  strong 
typing,  which  means  that  expressions  are  type  consistent  and  thus  type  errors  can  not 
occur  at  run-time,  and  that  the  type  of  every  expression  can  be  determined  by  static 
program  analysis  rather  than  during  program  execution,  helps  in  debugging  since 
one  is  guaranteed  that  if  a  program  compiles  successfully  then  no  error  can  occur 
at  run-time  due  to  type  violations.  It  also  leads  to  more  efficient  implementations, 
since  it  allows  one  to  eliminate  most  run-time  tags  and  type  testing,  but  it  may  lead 
to  a  loss  of  flexibility  and  expressive  power.  While  a  monomorphic  type  system  in 
which  every  value  can  be  interpreted  to  be  of  one  and  only  one  type  is  too  restrictive 
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in  its  expressive  power,  a  function  that  is  assigned  a  type  expression  with  one  or 
several  type  variables  is  said  to  be  polymorphic,  which  means  that  it  can  have  several 
different  types.  Overloading  can  likewise  assume  different  types.  However,  it  is  just 
the  use  of  one  function  symbol  for  many  different  but  usually  related  functions.  For 
an  overloaded  function,  a  definition  must  be  given  for  each  possible  argument  type 
while  a  polymorphic  function  is  defined  in  a  single  definition.  Polymorphic  functions 
are  extremely  useful.  In  one  function  definition,  we  define  a  number  of  functions  that 
are  computationally  similar.  Without  polymorphism  we  have  to  give  one  definition  for 
each  case.  Polymorphism  makes  programming  simpler  since  we  can  define  functions 
that  are  useful  in  a  variety  of  applications.  Polymorphism  is  not  confined  to  functional 
languages,  but  it  reflect  the  importance  of  higher-order  functions  to  the  expressive 
power  of  functional  languages.  It  is  generally  desirable  for  a  language  to  be  statically 
checked  using  a  powerful  and  strong  type  system. 


1.2  Storage  Management  Overhead 

A  high  implementation  overhead  is  required  to  support  a  variety  of  features  that  are  provided 
by  a  functional  language.  Despite  a  number  of  approaches  to  implementing  functional 
languages,  all  implementations  deal  with  the  same  basic  underlying  issues,  i.e.  dynamic 
allocation  of  heap  objects  and  garbage-collected  reclamation  of  them.  The  overhead  due  to 
storage  management  is  one  of  the  major  overheads  of  functional  language  implementations. 
The  principal  sources  of  the  storage  management  overhead  are  dynamic  allocation  and 
automatic  reclamation  of  indefinite  extent  storage. 

Dynamic  Heap  Allocation 

Heap  is  a  storage  which  is  allocated  and  reclaimed  dynamically  in  any  order  at  any  time 
during  a  program’s  execution.  There  are  two  kinds  of  run-time  objects  to  be  dynamically 
allocated  in  indefinite- extent  heap  storage  during  the  execution  of  a  functional  program 

([31]): 

•  Objects  built  explicitly  by  the  program  such  as  records,  lists  and  trees  whose  size  can 
vary  during  the  running  of  a  program  and  thus  cannot  be  statically  determined. 

•  Objects  built  by  the  implementation  such  as  closures  for  representing  function  values 
and  delayed  expressions. 
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Ill  the  implementation  of  a  language  with  implicit  storage  management,  data  structures 
which  are  defined  explicitly  in  a  program  but  whose  size  cannot  be  statically  determined, 
such  as  lists,  trees,  records  and  so  on,  are  generally  allocated  in  the  heap.  Heap  is  also  needed 
to  support  higher-order  functions  and  non-strict/lazy  semantics  of  functional  languages. 
The  need  for  heap  allocation  arises  when  parameters  and  locally  defined  objects  within  a 
function  outlive  a  call  to  that  function.  In  programming  languages  which  do  not  support 
higher-order  functions,  lifetime  of  storage  for  local  variables  are  confined  to  a  function’s 
activation  record.  Thus,  storage  for  the  locals  is  allocated  when  activation  begins  and  is 
deallocated  when  the  activation  ends. 

A  closure  is  a  means  of  representing  function  values,  which  consists  of  code  together 
with  its  free  variables.  The  use  of  closures  guarantees  that  variables  are  statically  scoped. 
In  languages  with  higher-order  functions  and  lexical  scoping  rules,  it  is  possible  to  write 
a  function,  say  /,  which  returns  a  lexically  enclosed  function,  say  g.  Allocating  the  envi¬ 
ronment  for  the  function  value  on  the  heap,  however,  adds  a  large  cost  to  each  function 
call. 

To  implement  non-strict  semantics  and  lazy  evaluation,  any  implementation  strategy 
uses  a  notion  of  delayed  expression  in  some  way,  but  in  the  abstract  they  all  do  the  same 
thing:  delay  the  evaluation  of  an  expression  until  its  value  is  demanded,  then  evaluate  it 
whenever  needed  (in  normal-order  implementation),  and  save  the  value  so  that  it  may  be 
used  on  future  demands  without  recomputation  (in  lazy  implementation).  Delayed  repre¬ 
sentation  of  an  expression  must  contain  enough  information  to  enable  the  expression  to  be 
evaluated  later.  Moreover,  in  order  to  implement  lazy  evaluation  in  which  the  expression 
is  guaranteed  to  be  evaluated  at  most  once,  there  must  additionally  be  some  mechanism 
to  cache  the  value  of  the  expression  and  return  it  later  rather  re-evaluating  it.  Creating  a 
delayed  expression  requires  the  allocation  of  some  storage.  Because  the  value  of  the  delayed 
expression  might  be  needed  at  some  unknown  time  in  future,  it  must  be  allocated  in  a  heap 
which  has  an  indefinite  extent. 

Automatic  Storage  Reclamation 

An  implementation  of  a  programming  language  with  dynamic  heap  allocation  requires  some 
kind  of  storage  reclamation  mechanism,  either  explicit  or  implicit( automatic),  because  the 
heap  storage  occupied  by  objects  which  are  inaccessible  and  are  no  longer  required  in  the 
execution  of  the  program  have  to  be  automatically  reclaimed  so  that  the  physically  finite 
storage  is  not  rapidly  exhausted  by  the  program.  Automatic  storage  reclamation  is  espe- 
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dally  important  in  implementations  of  dedarative  languages,  sudi  as  functional  languages, 
that  have  no  notion  of  explicit  storage  control  and  tend  to  use  storage  extensively.  There 
are  three  basic  approaches,  with  a  number  of  variants,  to  automatically  reuse  the  portions 
of  heap  storage,  called  garbage,  that  have  previously  been  allocated  but  are  no  longer  used 
by  the  program:  ([24],  [70])  reference  counting,  mark- and- sweep  garbage  collection ,  and 
copying  garbage  collection. 

On  most  current  computer  systems,  heap  allocation  and  automatic  storage  reclamation 
is  relatively  expensive.  A  significant  amount  of  overhead  both  in  time  and  in  space,  are 
incurred  in  the  process  of  automatic  storage  reclamation.  A  substantial  portion  of  the 
execution  time  is  spent  in  automatic  storage  reclamation.  Due  to  this  storage  management 
overhead,  in  conventional  computer  architectures,  typical  implementations  of  functional 
programs  are  inefficient  and  waste  memory,  and  thus  functional  programs  tend  to  be  much 
slower  than  their  imperative  equivalents. 

1.3  The  Role  of  Lifetime  Information 

Like  many  other  programming  language  implementations,  efficient  storage  management  is 
a  central  concern  in  functional  language  implementations.  The  approaches  to  reduce  the 
storage  management  overhead  due  to  dynamic  heap  allocation  and  garbage  collection  in 
functional  language  implementations  can  generally  be  classified  into  three  ways  as  follows: 

1.  Avoid  heap  allocation  and  garbage  collection  by  using  a  storage  structure  (for  example, 
a  stack)  whose  allocation  and  reclamation  is  more  efficient  than  for  a  heap.  A  heap 
provides  a  very  general  storage  allocation  mechanism,  but  it  is  also  very  expensive.  In 
contrast,  a  stack  is  much  less  flexible  allocation  mechanism,  but  the  store  it  allocates 
is  recovered  immediately  when  it  becomes  unused,  and  this  recovery  simply  involves 
decrementing  the  stack  pointer. 

2.  Even  though  heap  allocation  and  garbage  collection  is  used,  reduce  the  frequency 
of  invoking  the  garbage  collection  by  reducing  the  frequency  of  running  out  of  free 
storage. 

3.  Even  though  the  garbage  collection  is  invoked,  improve  the  garbage  collection  scheme 
itself  rather  than  fully  relying  on  the  original  garbage  collection  scheme. 

We  describe  a  variety  of  storage  management  optimization  techniques  as  follows: 
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•  Stack  Allocation  :  Objects  that  would  otherwise  be  allocated  in  the  heap  and  then 
reclaimed  using  garbage  collection  are  allocated  in  the  stack  and  cheaply  reclaimed 
without  invoking  garbage  collection.  ([16],  [20],  [34],  [42],  [55],  [76]) 

•  Explicit  Reclamation  and  In-place  Reuse  :  When  heap- allocated  objects  are  no  longer 
needed,  they  can  be  reclaimed  into  a  free  storage  list  explicitly  by  the  program  without 
invoking  a  garbage  collection  process.  When  heap- allocated  objects  are  no  longer 
needed,  their  storage  can  be  reused  directly  in  the  allocation  of  new  objects  without 
invoking  garbage  collection.  ([11],  [35],  [41],  [49],  [50],  [51]) 

•  Reference  Counting  Elimination  :  In  reference  counting,  each  object  contains  a  count, 
called  the  reference  count,  of  the  number  of  references  (pointers)  pointing  to  it.  Each 
time  a  reference  is  created  or  destroyed  its  reference  count  needs  to  be  incremented 
or  decremented.  It  is  desirable  for  unnecessary  updatings  on  reference  counts  at  each 
reference’s  creation/  deletion  to  be  avoided.  ([9],  [32]) 

•  Block  Allocation/Reclamation  :  A  number  of  objects  are  allocated  together  in  a  con¬ 
tiguous  block  of  a  heap  storage  and  the  whole  block  is  put  on  the  free  list,  rather 
than  the  individual  objects.  This  allows  reclamation  of  larger  segments  of  storage, 
and  reduces  run-time  overhead  by  avoiding  the  traversal  of  the  individual  objects  (in 
mark-sweep  collection,  for  instance).  ([76]) 

The  main  reason  that  objects  are  allocated  on  a  heap  is  that  their  lifetime  is  gener¬ 
ally  unknown  at  compile-time  and  thus  is  assumed  to  have  indefinite  extent.  In  principle, 
garbage  collection  can  be  avoided  by  compile-time  scheduling  of  storage  use.  Information 
about  the  lifetimes  of  objects  can  have  an  important  role  in  storage  management  optimiza¬ 
tions.  Objects  allocated  on  the  heap  could  be  allocated  and  reclaimed  more  efficiently  if 
compilers  sought  to  extract  information  about  their  lifetimes  from  the  program  text  instead 
of  making  worst-case  assumptions.  Stack  allocation  can  be  safely  applied  when  the  lifetimes 
of  objects  are  contained  in  the  lifetime  of  a  storage  which  can  be  reclaimed  in  the  reverse 
order  of  that  in  which  it  is  allocated.  Explicit  reclamation  and  in-place  reuse  can  be  applied 
when  the  lifetimes  of  heap-allocated  objects  are  known.  Reference  counting  elimination  can 
be  applied  when  the  lifetimes  of  references  to  a  heap- allocated  object  are  known.  Block 
allocation/reclamation  can  be  applied  when  a  set  of  objects  whose  lifetimes  are  same  are 
to  be  allocated  on  a  heap. 
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1.4  Lazy  Evaluation  Overhead  and  the  Role  of  Order-of- 
Demand  Information 

Many  modern  functional  languages  adopt  a  non-strict  semantics  and  use  the  lazy  evaluation 
model.  In  a  non-strict  functional  language,  arguments  in  a  function  application  are  not 
evaluated  unless  and  until  their  values  are  demanded.  An  optimized  version  of  normal- 
order  evaluation  is  lazy  evaluation  in  which  each  argument  is  evaluated  only  when  its  value 
is  first  demanded,  and  the  value  is  saved  for  later  demands.  The  implementation  of  lazy 
evaluation,  however,  involves  substantial  overhead  due  to 

1.  The  need  for  delaying  the  evaluation  of  arguments. 

2.  The  need  for  checking  their  evaluation  status  (that  is,  whether  they  have  already  been 
evaluated)  every  time  their  values  are  demanded. 

In  a  non-strict  functional  language  that  is  implemented  using  lazy  evaluation,  exact 
information  about  which  arguments  to  a  function  will  be  demanded,  what  the  order  of 
evaluation  among  the  arguments  of  a  function  is,  and  what  the  evaluation  status  of  an 
argument  is  when  its  value  is  demanded,  cannot  generally  be  decided  at  compile-time. 
If  such  information  could  be  safely  approximated  at  compile-time,  however,  a  number  of 
important  optimizations  could  be  performed.  Devising  such  analyses  and  optimizations  has 
been  a  major  focus  of  functional  language  research  over  the  past  decade. 

Information  about  which  arguments  to  a  function  will  definitely  be  demanded,  called 
strictness  information ,  is  used  to  optimize  lazy  evaluation  by  converting  lazy  evaluation 
into  applicative-order  evaluation  and  thus  reducing  the  overhead  of  lazy  evaluation  ([36], 
[31],  [63],  [66]).  Information  about  the  order  of  evaluation  of  the  arguments  to  a  function 
can  be  useful  for  a  number  of  optimizations,  including  copy  elimination  ([11],  [30],  [35]) 
and  process  scheduling  in  a  parallel  system  [13].  Information  on  the  status  of  evaluation  of 
arguments  when  they  are  demanded  is  useful  for  eliminating  unnecessary  checking  [14]  and 
for  efficient  storage  management  of  delayed  expressions  (closures). 

These  information  can  be  reformulated  in  terms  of  information  about  the  order  in  which 
the  values  of  bound  variables  are  demanded,  called  order-of-demand  information,  as  follows: 

•  Status  of  Evaluation :  Given  an  occurrence  xt  of  a  variable  x  in  the  body  of  a  function 
/,  if  for  each  possible  execution  of  the  body  of  /  there  exists  another  occurrence  xj  of 
x  such  that  xj  is  demanded  before  xt.  then  we  know  that  x  must  have  been  evaluated 


by  the  time  xl  is  encountered.  Thus  no  run-time  test  of  x's  status  is  required  to  obtain 
the  value  of  xt. 

•  Order  of  Evaluation :  Given  two  parameters  x  and  y  of  a  function  /,  if  for  every 
occurrence  yt  of  y  in  the  body  of  /  there  exists  an  occurrence  x j  of  x  that  is  demanded 
before  yt ,  then  we  can  conclude  that  x  will  always  be  evaluated  before  y. 

•  Strictness :  Given  a  parameter  a;  of  a  function  /,  if  we  can  determine  that  for  each  pos¬ 
sible  (terminating)  execution  of  the  body  of  /  some  occurrence  Xi  of  x  was  demanded, 
then  we  can  determine  that  /  is  strict  with  respect  to  x 


1.5  Semantics-based  Analysis 

Compiler  optimizations  should  not  affect  the  standard  semantics  of  programs,  but  may  af¬ 
fect  the  pragmatics  of  programs.  Any  compile-time  program  analysis  for  optimization  is 
required  to  be  semantically  correct  or  safe  with  respect  to  the  standard  semantics.  For 
functional  programming  languages  that  have  precise,  straightforward  semantics,  denota- 
tional  semantics  ([4],  [74],  [79])  and  abstract  interpretation  ([2],  [17],  [25],  [26],  [46],  [44], 
[63])  are  particularly  powerful  tools  for  general  and  effective  program  analyses  to  infer 
certain  properties  of  programs  that  may  be  needed  for  semantics-preserving  optimizations. 

Denotational  Semantics 

To  perform  meaning-preserving  optimizations,  a  precise  semantics  is  needed  for  any  pro¬ 
gramming  language.  Because  of  their  sound  theoretical  foundation,  functional  languages  are 
particularly  well  suited  for  semantics-based  analysis  of  programs.  Denotational  semantics  is 
a  formal  way  of  describing  the  (standard  or  non-standard)  meaning  of  a  program  in  terms 
of  mathematical  semantic  domains  that  properly  capture  our  intuition  about  program  be¬ 
haviors  and  semantic  functions,  and  is  the  most  widely  used  tool  for  describing  the  formal 
semantics  of  functional  programming  languages. 

Domain  theory  and  denotational  semantics  were  introduced  to  give  meaning  to  syntac¬ 
tic  expressions.  Formally,  we  consider  the  meaning  of  an  expression  to  be  a  value  taken 
from  some  domain  with  well  understood  mathematical  properties.  To  properly  represent 
the  results  of  all  computations,  a  suitable  domain  must  include  elements  representing  in¬ 
completely  evaluated  objects,  and  thus  represent  approximations  to  completely  evaluated 
objects.  Therefore,  we  need  an  ordering  establishing  a  partial  order  based  on  the  definedness 
of  elements  and  a  least  element  on  the  domain  D  representing  the  completely  undefined 
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object  (e.g.  non-termination).  We  also  require  that  domains  include  the  limits  of  infinite 
chains  of  approximating  partial  elements,  i.e.  for  each  increasing  sequence  in  D ,  the  least 
upper  bound  exists,  making  D  a  complete  partial  orderfcpo).  A  domain  D  is  called  flat 
when  all  elements  apart  from  the  bottom  element  are  incomparable  with  each  other.  For 
functions  defined  only  on  values  which  do  not  include  compound  data  types  such  as  lists, 
this  type  of  domain  is  sufficient  for  defining  a  consistent  semantics.  In  a  domain  which  is 
not  flat,  called  a  non-flat  domain,  there  may  exist  an  ordering  among  all  elements.  Com¬ 
putable  functions  between  domains  should  preserve  the  information  ordering  structure  and 
the  limits,  i.e.  they  are  monotonic  and  continuous.  Given  domains  with  these  requirements, 
we  can  construct  domains  such  as  the  Cartesian  product,  the  function  space,  the  separate 
sum,  the  coalesced  sum,  the  reflexive  domain,  the  functional  domain  and  the  powerdomain. 
We  can  now  interpret  recursively  defined  functions  as  least  fixed  points  and  also  compute 
them  by  iteration  from  the  fixed  point  theorem  [74],  If  the  domain  D  is  finite  or  it  has  the 
property  that  all  chains  are  of  finite  length,  then  the  least  fixpoint  can  be  computed  in  a 
finite  steps  by  iteration.  The  fixpoint  theorem  also  forms  the  basis  for  a  number  of  practical 
algorithms  in  abstract  interpretation. 

In  denotational  semantics,  the  semantics  of  a  language  is  defined  by  semantic  functions 
mapping  syntax  of  the  language  to  a  suitable  domain  that  captures  certain  computational 
behavior.  Such  semantic  functions  are  defined  so  that  the  meaning  of  any  composite  syn¬ 
tactic  structure  is  expressed  in  terms  of  the  meanings  of  its  immediate  constituents.  The 
standard  or  non-standard  semantics  of  any  functional  programming  language  can  be  ex¬ 
pressed  in  terms  of  a  domain  of  objects  and  continuous  functions  defined  on  it. 

Abstract  Interpretation 

Abstract  interpretation  is  a  computation  over  some  abstraction  or  approximation  of  a  se¬ 
mantic  domain.  It  is  a  formal  methodology  that  mathematically  approximates  uncom- 
putable  semantic  properties  and  can  be  related  directly  back  to  the  original  denotational 
semantics.  The  correctness  can  be  proved  at  an  abstract  level,  independently  of  operational 
concerns.  From  a  practical  perspective,  abstract  interpretation  also  provides  a  convenient 
methodology  for  expressing  compile-time  analyses  in  a  relatively  language-independent  man¬ 
ner.  Abstract  interpretation  can  be  used  as  a  general  technique  for  deducing  information 
about  a  program  from  its  text,  by  executing  an  abstract  version  of  the  program  with  ab¬ 
stract  data  and  then  extracting  desired  information  from  the  abstract  results,  instead  of 
actually  executing  the  original  program  and  then  extracting  some  information  via  a  given 
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standard  or  non-standard  semantics.  Abstract  interpretation  lias  the  advantages  of  han¬ 
dling  inter-functional  dependency,  recursion,  higher-order  functions,  and  aggregate  data 
structures.  Most  information  the  we  want  to  know  about  the  program  is  essentially  unde- 
cidable.  Therefore  the  issues  of  effective  computability  and  semantic  correctness  or  safety 
become  crucial  for  program  analysis  through  abstract  interpretation. 

Abstract  interpretation  in  the  functional  idiom  analyzes  certain  properties  of  an  expres¬ 
sion’s  evaluation  by  first  defining  an  appropriate  abstract  domain  which  is  usually  much 
simpler  than  the  exact  standard  or  non-standard  semantic  domain,  having  the  minimum 
structure  required  to  encapsulate  these  properties,  and  defining  an  abstract  version  of  each 
function  occurring  in  the  expression  on  the  abstract  domain.  Then  the  abstract  version 
of  each  function  is  applied  to  the  abstractions  of  its  arguments  to  give  a  result,  also  in 
the  abstract  domain,  from  which  the  required  properties  of  the  function’s  real  application 
can  be  deduced.  The  safety  criteria  of  an  abstract  interpretation  is  that  the  real  result  of 
the  application  of  a  function  is  in  the  set  represented  by  the  result  of  the  corresponding 
application  of  the  abstracted  function.  To  be  certain  of  being  correct,  we  must  consider 
every  possible  outcome  of  the  computations  represented  by  a  given  abstract  value,  only  one 
of  which  will  occur  in  any  particular  instance.  Of  course,  by  enriching  the  abstract  domain 
sufficiently,  we  could  represent  any  property  completely  and  make  precise  predictions  pos¬ 
sible,  but  ultimately  we  would  arrive  back  at  the  given  original  standard  or  non-standard 
domain  itself  and  have  to  do  the  whole  computation  anyway.  Normally,  the  applications 
in  the  abstract  domain  are  sufficiently  simple  that  they  can  be  effectively  performed  at 
compile-time.  Thus,  optimizations  relying  on  information  from  abstract  interpretation  can 
be  performed  at  compile-time. 

1.6  Overview  of  the  Thesis 

The  main  reason  that  objects  are  allocated  on  a  heap  is  that  their  lifetime  are  generally 
unknown  at  compile-time.  This  property  of  object  is  called  indefinite  extent.  Information 
about  the  lifetimes  of  objects  can  have  an  important  role  in  storage  management  optimiza¬ 
tions.  Objects  allocated  on  the  heap  could  be  allocated  and  reclaimed  more  efficiently  if 
compilers  sought  to  extract  information  about  their  lifetimes  from  the  program  text  instead 
of  making  worst-case  assumptions.  In  functional  languages  among  many  other  languages, 
exact  information  about  lifetimes  of  objects  is  generally  not  known  at  compile-time,  but  can 
be  known  only  at  run-time.  Such  information,  if  inferred  at  compile-time,  allows  a  variety 
of  optimizations  that  reduce  the  storage  management  overhead. 
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Ill  this  thesis,  using  formal  denotational  semantics  and  the  abstract  interpretation  tech¬ 
nique,  we  develop  a  set  of  compile-time  semantic  analyses  for  higher-order,  polymorphic 
functional  languages  with  non-flat  domains,  which  provide  safe  information  about  the  life¬ 
time  of  dynamically- allocated  objects  during  a  program’s  execution.  Based  on  the  infor¬ 
mation  that  is  inferred  statically  through  compile-time  analyses,  we  investigate  a  vari¬ 
ety  of  storage  management  optimization  techniques  that  reduce  the  storage  management 
overhead  in  functional  language  implementations  including  bounded- extent  storage  alloca¬ 
tion,  explicit  reclamation,  in-place  reuse,  reference  counting  elimination,  and  block  alloca¬ 
tion/reclamation. 

1.6.1  The  Functional  Language 

We  introduce  a  simple  higher-order  functional  language  which  is  representative  of  a  class 
of  modern  functional  programming  languages  and  will  be  used  throughout  the  thesis.  It 
is  a  common  observation  that  the  syntax  of  modern  high  level  functional  programming 
languages  are  sugared  versions  of  the  lambda  calculus  ([8],  [67]).  We  view  our  analysis  as 
being  performed  at  the  high-level  expression-oriented  source  code,  not  at  low-level  target 
code.  This  view  is  more  portable,  though  the  other  view  has  the  possible  advantage  being 
able  to  use  more  traditional  compiler  optimization  techniques.  Because  the  information  is 
derived  at  the  source  level  it  is  available  during  code  generation  regardless  of  the  target 
language  of  a  given  virtual  machine. 

As  a  model  language,  we  define  a  simple  higher-order  functional  language  whose  syntax 
is  based  on  the  typed  lambda  calculus  augmented  with  constants  that  include  primitive 
functions.  The  language  syntax  is  defined  in  Figure  1.1.  To  support  first-class  functions,  all 
functions  including  primitive  ones  are  curried  and  explicit  lambda  abstractions  are  allowed. 
Nested  groups  of  equations  are  also  allowed.  We  assume  that  all  identifiers  have  unique 
names,  i.e.  that  the  program  has  been  alpha- converted  to  ensure  that  all  bound  variables 
have  been  given  unique  names.  Data  structures  more  general  than  fists,  such  as  trees,  are 
not  dealt  with  here,  however,  the  methods  for  lists  could  be  extended  to  handle  general  free 
data  types  as  well.  The  model  language  is  defined  this  way  because  any  functional  language 
is  essentially  a  sugared  version  of  the  lambda  calculus,  and  a  number  of  semantic  analysis 
which  we  will  discuss  in  this  thesis  are  applied  to  high-level  source  programs.  We  assume 
that  the  functional  language  adopts  a  strong  static  type  system. 
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c  G  Con  Set  of  Const  ants  (including  primitive  functions) 

=  1,0, 1, . . . , true, false, nil,  cons,  car,  cdr,null} 

x  G  Id  Set  of  Identifiers 

e  G  Exp  Set  of  Expressions,  defined  by 

e  c  \  x  \  e\  -\-  02  \  —  02  \  ei  —  e2  |  if  e\  then  e2  else  es 

|  eie2  |  lambda) a;). e  |  letrec  x\  =  e\\  . . xn—  en;  in  e 
pr  G  Program  Set  of  Programs,  defined  by 

pr  ::=  letrec  x\  =  ;  i„  =  e„;  in  e 

Figure  1.1:  The  Syntax  of  Functional  Language 

Notational  Conventions 

Throughout  this  thesis,  the  following  conventional  notations  are  adopted; 

1.  Double  bracket,  [  ],  is  used  to  surround  syntactic  objects, 

2.  Square  bracket  and  map  arrow,  [  1 —  ],  are  used  for  environment  updates, 

3.  Angle  bracket,  (  ),  is  used  for  tupling, 

4.  Subscripts  of  (1),  (2)  and  (3)  are  used  to  denote  the  first,  second  and  third  element  of 
a  tuple,  respectively  and  a  subscript  of  (1,2)  is  used  to  denote  a  pair  consisting  of  the 
first  and  second  elements  of  a  tuple. 

1.6.2  Strict  and  Non-strict  Standard  Semantics 

In  strict  languages,  the  reduction  of  a  function  application  is  performed  in  applicative- 
order  and  thus  the  application  of  a  function  to  its  arguments  results  in  the  arguments 
being  evaluated  before  they  are  passed  to  the  function.  This  section  describes  the  standard 
denotational  semantics  for  the  model  higher-order  functional  language. 

Standard  Semantic  Domains 

The  meaning  of  an  expression  under  the  standard  semantics  is  the  value  of  the  expression 
that  we  usually  think  of,  such  as  a  number,  boolean  value,  function  or  list.  The  standard 
semantic  domain  Ds  and  the  domain  of  standard  environments  Es  that  is  a  domain  of 
functions  mapping  identifiers  on  to  their  standard  meaning  are  defined  as  follows: 
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Ds  =  /*  Standard  semantic  domain  */ 

Es  =  Id  —  yj,s  /*  Domain  of  standard  environments  * / 

The  standard  semantic  domain  Ds  is  a  separated  sum  domain  consisting  of  a  subdomain 
for  each  type.  The  standard  subdomain  DTS  for  expressions  of  type  r  is  defined  as  follows: 

D lJlt  =  {-Lint}  +  —1 , 0, 1, . . .}  subdomain  for  integers 

£)bool  —  -)-  {true,  false}  subdomain  for  booleans 

DTS1^T2  =  D J1  —  D l2  subdomain  for  functions  of  type  T\  — >  T2 

DTS  llst  =  {Tr  nst}  +  {nil1  hst}  subdomain  for  lists  of  type  t  list 

•H  x  dj  Z!st) 

Standard  Semantic  Functions 

We  introduce  the  standard  strict  semantic  functions  as  follows: 

Sc  :  Con  —‘Dg  /*  Standard  semantic  function  for  constants  */ 

Se  :  Exp  — >  Es  — >  Ds  /*  Standard  semantic  function  for  expressions  */ 

:  Program  /*  Standard  semantic  function  for  programs  */ 

The  standard  semantic  function  Sc  gives  standard  meaning  to  constants.  The  standard 
semantic  function  S,  gives  standard  meaning  to  expressions  in  a  given  standard  environment 
for  identifiers.  The  standard  semantic  function  Spr  gives  standard  meaning  to  programs. 
The  semantic  equations  for  the  standard  semantic  functions  are  expressed  in  Figure  1.2. 
Here,  the  symbol  of  As  is  used  to  denote  a  strict  function  abstraction  compared  with  an 
ordinary  notation  of  A. 


-L  y  =  -Uj 

(Az.e)  y  y  ±  ±n 


envs  denotes  any  standard  environment  in  Es,  and  nullenvs  is  a  standard  environment  that 
maps  every  identifier  on  to  the  least  element  of  its  standard  semantic  domain.  Note  that 
Se  and  env's  is  recursively  defined. 

The  standard  semantic  functions  for  non-strict  semantics  are  defined  as  the  standard 


semantic  functions  for  strict  semantics  in  which  As  is  replaced  by  A. 


1.6.3  Organizations 

The  rest  of  the  thesis  is  organized  as  follows: 
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Sole] 

,5'c[true] 

Sc  [false] 
6'c[nilT  list ] 
5c[cons] 
Sc[car] 
Sc[cdr] 

Sc  [null] 


c,  c  G  {. . . ,  —  1,  0, 1, . . .} 

true 

false 

nllT  list 

Xsx.X sy.  p air ( x,  y ) where  pair (x,y)  =  {x,y) 
Xsx.  first  (a:)  where  first  (a;)  =  xm 
Xsx.  second(a;)where  second(x)  =  X(2) 

Xsx.  if  (x  =  nil)  then  true  else  false 


Se\c\envs 
Se\x\envs 
Se[ei  +  e2jenvs 
Se\e i  -  e2Jenvs 
Se[ei  =  e2jenvs 


=  Sc[c] 

=  envs\x\ 

=  Selei}envs  +  Sele2}envs 
=  Seletjenvs  -  Se{e2}envs 

=  if  (5e[ei]enns  =  Sele2Jenvs)  then  true  else  false 
5e[if  ei  then  e2  else  es Jenvs  =  if  (Se[ei]erit;s  =  true) 

then  Se\e2\envs  else  S,  [f  3 |<  nvs 
Seleie2}envs  =  (Se[ei]em^)(Se[e2]e7uv) 

6'e[lambda(a).e]enr;s  =  Xsy.Se[e\envs[x  y] 

5'e[letrec  x\  —  Cj; . . . ;  xn  —  en\  in  e\envs  =  Se\e\env's 


where  env's  =  envs[ x\  Se\e-\\env'a , . . . ,  xn  5e[en]enu'] 

<%./•[ /•'/■]  =  Se\pr\nullenvs 


Figure  1.2:  Standard  Semantic  Functions 
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•  Chapter  2.  Escape  Analysis  :  In  a  higher-order  functional  language,  exact  in¬ 
formation  about  the  lifetime  of  objects,  such  as  bound  variables,  within  a  function 
compared  to  the  lifetime  of  the  activation  of  the  function  call  is  generally  unknown  at 
compile-time,  and  can  only  be  completely  determined  at  run  time.  This  chapter  de¬ 
scribes  a  method  for  computing,  at  compile-time,  safe  information  about  the  relative 
lifetime  of  arguments  and  local  objects  within  a  function  with  respect  to  the  lifetime 
of  an  activation  of  the  function  call.  This  analysis  is  described  for  a  monomorphic, 
strict,  higher-order  functional  language.  The  method  is  based  on  a  compile-time  se¬ 
mantic  analysis  called  escape  analysis  which  provides  information  about  the  lifetimes 
of  objects  within  a  function  with  respect  to  the  lifetime  of  the  activation  of  a  function 
call.  This  information  is  called  the  escapement  of  objects. 

•  Chapter  3.  Refinements  of  Escape  Analysis  :  For  structured  objects  such  as 
lists  and  trees,  the  escape  information  that  is  obtainable  through  the  escape  analysis 
is  rather  coarse.  This  chapter  describes  a  method  for  computing  more  refined  escape 
information  for  a  monomorphic,  strict,  higher-order  functional  language.  This  method 
is  based  on  a  compile-time  semantic  analysis  called  refined  escape  analysis  which  is  an 
extension  of  escape  analysis  and  determines  at  compile-time  how  much  of  an  object 
outlives  the  activation  of  the  function  call  in  which  it  is  created. 

•  Chapter  4.  Reference  Escape  Analysis  :  In  a  higher-order  functional  language, 
exact  information  about  the  lifetime  of  a  dynamically  created  reference  (pointer)  to  a 
heap- allocated  object  is  generally  unknown  at  compile-time.  This  chapter  describes  a 
method  for  computing,  at  compile-time,  safe  information  about  the  relative  lifetime 
of  dynamically  created  references.  This  method  is  based  on  a  compile-time  semantic 
analysis  called  reference  escape  analysis. 

•  Chapter  5.  Order-of-Demand  Analysis  :  In  a  non-strict  functional  language 
with  lazy  evaluation,  exact  information  about  the  strictness  of  arguments,  the  order  of 
evaluation  among  arguments,  and  the  evaluation  status  of  arguments  when  demanded 
is  generally  unknown  at  compile-time.  This  chapter  describes  a  method  for  statically 
inferring  a  range  of  information  including  strictness,  evaluation-order,  and  evaluation- 
status  information.  This  method  is  based  on  a  compile-time  analysis  called  order-of- 
demand  analysis  which  provides  safe  information  about  the  order  in  which  the  values 
of  bound  variables  are  demanded. 
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•  Chapter  6.  Polymorphic  Invariance  :  All  the  semantic  analyses  presented  in 
the  preceding  chapters  have  dealt  with  a  higher-order  functional  language  with  a 
monomorphic  type  system.  Using  the  notion  of  polymorphic  invariance,  this  chapter 
describes  a  method  for  applying  escape  analysis,  reference  escape  analysis,  and  order- 
of-demand  analysis  to  a  polymorphic  language  using  the  analysis  techniques  for  a 
monomorphic  language. 

•  Chapter  7.  Extensions  to  Non-st rict  Languages  :  Many  modern  functional 
languages  adopt  a  non-strict  semantics  using  the  lazy  evaluation  model,  which  is  more 
powerful  than  strict  languages  in  its  expressiveness.  Using  program  transformation, 
this  chapter  describes  the  extensions  of  escape  analysis  and  reference  escape  analysis 
to  a  non-strict  language. 

•  Chapter  8.  Storage  Management  Optimizations  :  The  escape  information  that 
is  inferred  at  compile-time  from  the  semantic  analyses  which  have  been  described 
in  previous  chapters,  allows  a  variety  of  storage  management  optimizations  in  func¬ 
tional  language  implementations.  Using  the  statically  inferred  escape  information, 
this  chapter  describes  a  variety  of  optimization  techniques  to  reduce  the  storage  man¬ 
agement  overheads  in  functional  language  implementations,  including  stack(bounded- 
extent  storage)  allocation,  explicit  reclamation,  in-place  reuse  of  garbage  cells,  refer¬ 
ence  counting  elimination,  block  allocation/reclamation,  and  improving  generational 
garbage  collection. 

•  Chapter  9.  Related  Work,  Conclusions,  and  Future  Work  :  This  chapter 
surveys  some  previous  work  related  to  the  work  presented  in  this  thesis,  summarizes 
the  contributions  of  this  thesis,  and  suggest  some  further  research  in  this  area. 
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Chapter  2 


Escape  Analysis 


In  liiglier-order  functional  languages,  exact  information  about  the  relative  lifetime  of  an 
object  with  respect  to  the  lifetime  of  the  activation  of  the  function  call  that  creates  the 
object  is  generally  unknown  at  compile-time.  When  storage  is  allocated  for  such  an  object, 
it  is  generally  allocated  from  a  heap.  The  object  is  then  reclaimed  using  some  kind  of 
automatic  reclamation  method.  Lifetime  information,  if  inferred  at  compile-time,  can  be 
useful  for  efficient  management  of  storage  for  these  objects  at  run-time. 

In  this  chapter,  we  present  a  method  for  computing  at  compile-time  safe  information 
about  the  relative  lifetime  of  arguments  and  local  objects  defined  within  a  function  with 
respect  to  the  lifetime  of  an  activation  of  the  function  call  for  a  higher-order,  monomorphic, 
strict  functional  language.  This  method  is  based  on  a  compile-time  semantic  analysis  called 
escape  analysis  which  provides  information  about  the  lifetimes  of  such  objects  with  respect 
to  the  activation  of  the  function  call  that  creates  them.  This  property  is  called  escapement  of 
objects.  First,  using  denotational  semantics  and  abstract  interpretation,  we  introduce  a  non¬ 
standard  denotational  semantics  called  escape  semantics  that  describes  the  actual  escape 
behavior,  but  is  incomputable  at  compile  time.  An  abstraction  method  for  approximating 
the  exact  escape  semantics  which  is  both  safe  with  respect  to  the  exact  escape  semantics  and 
computable  at  compile-time  is  then  presented.  Based  on  this  abstract  escape  semantics ,  we 
describe  the  escape  testing  algorithms  which  determine  escape  information  for  functions  that 
holds  true  for  every  possible  application  of  the  function,  and  also  escapement  information 
that  holds  for  a  particular  call  to  the  function.  Another  safe  and  computable  abstraction 
of  the  exact  escape  semantics,  called  improved  abstract  escape  semantics,  that  improves  the 
precision  of  escape  information  that  is  obtainable  through  the  abstract  escape  semantics 
is  also  presented  using  the  position  information  of  objects  in  a  list  structure.  Finally,  the 
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Figure  2.1:  Escapement  of  Objects 
complexity  of  the  escape  analysis  is  discussed. 

2.1  Escapement  of  Objects 

The  lifetime  of  an  object  defined  in  a  program  is  the  period  from  the  time  it  is  created  to 
the  time  it  will  be  no  longer  used.  The  notion  of  relative  lifetime  is,  given  a  pair  of  objects 
0\  and  O2  being  built  during  a  program’s  execution,  whether  the  object  0\  has  a  greater 
lifetime  with  respect  to  the  lifetime  of  the  other  object  0 2  or  not.  The  notion  of  relative 
lifetime  can  be  applied  to  any  pair  of  objects  that  exist  during  a  program’s  execution.  We 
are  particularly  interested  in  the  case  when  one  object  is  either  an  argument  to  a  function 
or  a  locally  defined  object,  and  the  other  object  is  an  activation  (record)  of  the  function 
call,  as  is  shown  in  Figure  2.1.  That  is,  given  a  function,  we  are  interested  in  whether 
an  argument  or  a  locally  defined  object  escapes  the  activation  of  the  function  call  or  not. 
Note  that  the  escaping  argument  or  locally  defined  object  needs  to  be  retained  after  the 
activation  to  the  function  call  ends.  We  formally  define  the  notion  of  escapement  of  objects 
with  respect  to  a  function. 

Definition  2.1  (Global/Local  Escapement)  Given  a  function  /  with  n  formal  param¬ 
eters  and  m  locally  defined  objects,  the  ith  formal  parameter  or  locally  defined  object  is 
said  to 

•  escape  the  function  call  to  /  globally  if,  in  some  possible  application  of  /  to  n  ar¬ 
guments,  some  or  all  of  the  corresponding  actual  parameter  or  local  object  outlives 
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the  activation  of  the  function  call  (by  being  contained  in  the  result  of  the  function 
application). 

•  escape  the  function  call  to  /  locally  in  (/  e\  ...en)  if,  in  the  particular  function 
application  of  ( /  e\  . . .  en ) ,  some  or  all  of  the  corresponding  actual  parameter  or  local 
object  outlives  the  activation  of  the  particular  function  call  to  /  (by  being  contained 
in  the  result  of  the  function  application  of  (  /  e\  . . .  e„)). 

The  global  escape  information  about  a  function  can  be  safe  in  any  context  in  which  the 
function  is  called.  In  this  sense,  it  is  the  property  of  function  regardless  of  its  application 
context.  Thus,  the  global  escape  information  is  safe  for  a  function  in  a  particular  context, 
but  it  may  be  weaker,  in  terms  of  its  usefulness,  than  the  escape  information  of  a  function 
in  a  particular  context.  The  local  escape  information  about  a  function  is  the  property  of 
the  function  in  a  particular  context  rather  than  the  property  of  the  function  alone. 

From  the  escape  information  about  a  parameter  or  local  object  with  respect  to  a  func¬ 
tion,  we  can  deduce  information  about  its  lifetime:  If  a  parameter  or  local  object  does  not 
escape  the  function  call  to  /  globally  then  we  can  conclude  that  the  lifetime  of  the  corre¬ 
sponding  argument  or  local  object  that  is  created  inside  the  function  is  confined  within  the 
lifetime  of  the  function  call  in  any  possible  application  of  /  unless  it  is  shared  elsewhere. 
Similarly,  if  it  does  not  escape  the  function  call  to  /  locally  in  a  particular  context  of 
(fe i  . . .  en )  then  we  can  conclude  that  the  lifetime  of  the  corresponding  argument  or  local 
object  that  is  created  inside  the  function  is  confined  within  the  lifetime  of  that  particular 
function  call  unless  it  is  shared  elsewhere. 

Such  escape  information  is  generally  unknown  at  compile-time  in  higher-order  functional 
languages.  We  will  develop  a  method  for  monomorphic,  higher-order,  strict  functional 
languages  to  answer  the  following  questions  at  compile-time: 

•  Given  a  function,  which  parameter  or  local  object  that  is  defined  inside  the  function 
escapes  the  function  calf  globally  ? 

•  Given  a  function  in  a  particular  application  context,  which  parameter  or  local  object 
that  is  defined  inside  the  function  escapes  that  particular  function  call  locally  ? 

A  naive  approach  would  be  through  syntactic  analysis.  However,  such  syntax-based  ap¬ 
proach  is  not  sufficient  for  specifying  higher-order  escapements  of  objects.  We  formalize  the 
escape  model  through  denotational  semantics  and  then  derive  a  safe,  computable  analysis 
using  the  abstract  interpretation.  First,  we  define  a  non-standard  denotational  semantics 
that  captures  the  exact  operational  notion  of  escapements.  Since  the  functional  language 
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we  are  dealing  with  allows  higher-order  functions,  the  result  of  an  expression  may  be  a 
function.  Such  a  function,  represented  by  a  closure,  has  two  important  characteristics  with 
respect  to  the  escape  semantics: 

1.  The  closure  is  an  object  itself.  We  may  be  interested  in  whether  the  closure  escapes 
or  not,  or  we  may  be  interested  in  another  object  that  is  captured( bound)  within  the 
closure.  Thus,  the  value  of  an  expression  returning  a  function  must  indicate  whether 
an  interesting  object  has  escaped. 

2.  A  function  value  may  be  applied  to  arguments  (which  may  themselves  escape  from 
the  application).  Therefore,  in  the  non-standard  escape  semantics,  the  escape  value 
of  a  function  must  include  its  behavior  as  a  function. 

Thus,  the  value  of  an  expression  in  the  escape  semantics  is  an  element  of  a  non-standard 
semantic  domain  and  must  have  two  components.  First,  it  must  contain  information  about 
what  is  contained  within  the  value  of  the  expression.  Second,  it  must  capture  the  functional 
behavior  of  the  expression  over  the  values  in  the  escape  semantic  domain.  We  then  define  a 
suitable,  i.e.  safe  and  computable,  abstraction  of  the  exact  non-standard  semantics  that  can 
be  computed  at  compile  time  but  provide  less  precise  information.  Then  we  describe  how 
the  abstract  escape  semantics  can  be  used  to  gain  global  and  local  escape  information.  We 
also  describe  another  abstraction  of  the  exact  escape  semantics  that  provides  more  precise 
escape  information  but  at  a  higher  cost. 

2.2  Exact  Non-standard  Escape  Semantics 

We  introduce  an  exact,  but  incomputable,  non-standard  denotational  semantics  called  es¬ 
cape  semantics ,  which  exactly  describes  the  actual  operational  notion  of  escapement  for 
functions  in  a  program.  Since  the  exact  escapement  during  a  program’s  execution  depends 
on  the  standard  values  themselves,  for  example,  the  standard  value  of  the  predicate  part  of 
the  conditional  will  determine  which  alternative  will  be  taken,  any  exact  escape  semantics 
needs  to  contain  the  information  about  the  standard  meaning  as  well  as  escape  information. 

Each  parameter  or  local  object  of  a  function  will  be  analyzed  separately  to  determine 
its  escape  behavior.  We  say  that  a  parameter  is  interesting  if  it  is  the  one  whose  escape 
behavior  we  are  trying  to  determine.  Thus,  our  escape  semantics  is  defined  in  terms  of  a 
single  interesting  object. 
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Figure  2.2:  The  Basic  Escape  Domain 

Representing  Escape  Information 

The  first  step  in  describing  a  non-standard  escape  semantics  is  to  define  a  suitable  non¬ 
standard  escape  semantic  domain.  A  domain  is  used,  rather  than  a  set,  to  guarantee  that 
a  recursive  function  always  has  a  solution.  The  meaning  we  will  attach  to  the  syntax  is  the 
information  about  containment  of  interesting  objects.  For  each  expression,  its  corresponding 
value  in  the  escape  semantic  domain  should  be  able  to  tell  whether  no  part  of  an  interesting 
object  is  contained  in  the  value  of  the  expression  (“non- escape”),  or  whether  some  part  of 
or  all  of  an  interesting  object  is  contained  in  the  value  of  the  expression  (“escape”).  Thus, 
under  our  non-standard  escape  semantics,  we  represent  the  meaning  of  an  expression  as  a 
pair,  called  an  escape  pair  (in  the  style  of  [43]), 

1.  whose  first  element  denotes  the  containment  of  an  interesting  object  in  the  value  of 
the  expression,  and 

2.  whose  second  element  denotes  the  functional  behavior  of  the  expression  defined  over 
the  escape  pairs  when  the  expression  itself  is  applied  to  another  expression. 

For  a  non- list  type  expression,  the  corresponding  value  in  the  non-standard  escape  semantic 
domain  D0  has  two  components;  The  first  component  is  an  element  of  a  domain  called  a 
basic  escape  domain,  B0  which  is  a  two-element  domain  of  0  and  1  ordered  by  0  C  1  as 
shown  in  Figure  2.2.  The  interpretation  of  elements  of  B0  is  defined  as  follows: 

•  1  :  Some  part  of  or  all  of  an  interesting  object  is  contained  in  the  value  of  the 
expression. 

•  0  :  No  part  of  any  interesting  object  is  contained  in  the  value  of  the  expression. 

The  second  component  is  a  function  over  D0,  whose  meaning  is  the  functional  behavior  of 
the  expression  defined  over  the  escape  values  when  the  expression  e  is  applied  to  another 
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expression.  For  expressions  which  have  no  higher-order  behavior,  such  as  non-function 
type  expressions,  err,  denoting  a  function  that  can  never  be  applied,  is  used.  For  a  list 
type  expression,  the  corresponding  value  in  the  escape  semantic  domain  is  a  list  of  the 
corresponding  values  of  its  components  in  the  escape  semantic  domain. 

Escape  Semantic  Domains 

D0 ,  the  escape  semantic  domain,  and  Ea ,  the  domain  of  environments  mapping  identifiers 
to  their  escape  meanings,  are  completely  defined  as  follows: 

D0  =  YPi  /*  Escape  semantic  domain  */ 

E0  =  Id  — >  D0  /*  Domain  of  escape  environments  */ 

The  escape  semantic  domain  D0  is  a  separated  sum  domain  made  up  of  the  subdomains  for 
each  type  defined  by  DTU .  The  escape  subdomain  Dl  for  expressions  of  type  r  is  defined  as 
follows  (in  the  style  of  [18]): 


T^int 

^  0 

=  B0  X  {err} 

subdomain  for  integers 

T^bool 
^  0 

=  B0  X  {err} 

subdomain  for  booleans 

Dl i^T2 

=  B0  X  (Dl1  —y  Dl2) 

subdomain  for  functions  of  type  T\  — >  r2 

J~)i~  list 
^  0 

=  (  B0  X  {err})  +  (  DT0  X  DTa  ltst ) 

subdomain  for  lists  of  type  r  list 

The  escape  subdomains  for  integers  and  boolean  values  is  the  cartesian  product  of  B0  and 
err,  which  is  ordered  as  follows: 

Vtt,  v  G  Dl0nt  °r  bo°l,  u  E  v  iff  (rip)  E  Wji))  and  (u(2)  E  V(2)) 

The  escape  subdomain  for  function  of  type  r1  — >  r2  is  the  cartesian  product  of  B0  and  the 
function  space  /J)1  —  l){2 .  The  function  space  of  I)}/  —  Dl2  is  ordered  as  follows: 

V/,5  G  Dl1  ^  Dl2,  f  C  g  iff  Vd  G  D?,/(2)  d  C  g{2)  d 

The  escape  subdomain  for  lists  of  type  r  list  is  the  sum  domain  of  the  cartesian  product 
of  B0  and  err,  and  the  cartesian  product  of  DTa  and  DT0ltst ,  whose  ordering  is  defined  as 
follows: 

Vu,  v  G  DT0  Ust,  u  C  v  iff  (  jj  p)  C  (  □  q) 

p  111  u  q  111  v 

where  p  in  u  denotes  that  p  is  an  escape  pair  in  u. 

The  bottom  elements  and  T i,00i  in  the  escape  subdomains  for  integers  and  booleans 
are  (0,  err),  respectively.  The  bottom  element  ±ri^T2  in  the  escape  subdomain  for  functions 
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of  type  7~i  — >  i~2  is  (0,  Aa\_LT2).  The  bottom  element  _Lr  usi  in  the  escape  subdomain  for  lists 
of  type  t  list  is  (0,  err). 

The  top  elements  T int  and  T bool  in  the  escape  subdomains  for  integers  and  booleans 
are  (1 ,  err),  respectively.  The  top  element  Tri_*T2  in  the  escape  subdomain  for  functions 
of  type  T\  —?  7"2  is  (1,  Aa\TT2).  The  top  element  Tr  usi  in  the  escape  subdomain  for  lists  of 
type  t  list ,  however,  does  not  exist. 

Escape  Semantic  Functions 

We  now  introduce  the  non-standard  escape  semantic  functions  to  give  the  syntax  the  escape 
meaning  as  follows: 

Oc  :  Con  D0  /*  Escape  semantic  function  for  constants  * / 

Oe  :  Exp  — >  E0  — *  D0  /*  Escape  semantic  function  for  expressions  */ 

0Pr  '■  Program  — >  D0  /*  Escape  semantic  function  for  programs  */ 

The  escape  semantic  function  Oc  gives  the  non-standard  escape  meaning  to  constants.  The 
escape  semantic  function  Oe  gives  the  non-standard  escape  meaning  to  expressions  in  a  given 
escape  environment  for  identifiers.  The  escape  semantic  function  Opr  gives  the  non-standard 
escape  meaning  to  programs  The  semantic  equations  for  the  escape  semantic  functions  are 
expressed  in  Figure  2.3. 

Since  an  interesting  object  is  definitely  not  contained  in  constants  such  as  integers, 
booleans  and  nil,  and  also  such  constants  can  never  be  applied,  their  values  in  escape 
semantics  are  given  by  (0 ,  err).  The  value  of  cons  under  escape  semantics,  when  applied 
to  two  arguments,  simply  returns  a  pair  consisting  of  the  values  of  the  two  arguments. 
Since  cons  is  curried,  the  result  of  applying  cons  to  a  single  argument  returns  a  closure 
containing  that  argument.  The  values  of  car  and  cdr  under  escape  semantics,  when  applied 
to  a  list  whose  value  is  a  pair  in  ZF llst,  returns  the  first  and  second  components  of  the  pair, 
respectively.  The  value  of  null  under  the  escape  semantics,  when  applied  to  a  list,  returns 
the  escape  values  of  constant  boolean  values,  namely  (0,err). 

env0  is  any  exact  escape  environment  in  Ea.  In  order  to  return  the  actual  escape  value 
of  each  expression,  we  must  be  able  to  determine  which  branch  of  the  conditional  primitive 
if  would  be  evaluated  at  run-time.  Here,  for  convenience,  we  instead  resort  to  an  oracle 
called  Oracle  to  choose  the  appropriate  branch  of  the  if.  Under  the  escape  semantics, 
the  value  of  a  lambda  expression  which  denotes  a  function  reflects  whether  an  interesting 
object  is  contained  in  the  resulting  closure  it  as  a  free  identifier,  as  well  as  its  functional 
behavior  when  it  is  applied.  Note  that  free  identifiers  are  treated  separately  according  to 
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whether  they  are  of  a  list  type  or  a  non-list  type.  nullenv0  is  an  escape  environment  that 
maps  every  identifier  to  the  least  element  of  its  escape  semantic  domain. 

Uncomputable  at  compile-time 

Oracle,  which  is  of  type  Exp  — *  {true,  false},  is  used  to  resolve  the  exact  escape  behavior 
of  the  conditional  expression  if.  Since  the  branch  of  the  if  that  is  actually  taken  depends 
on  the  standard  value  of  its  predicate  expression,  this  oracle  must  rely  on  the  standard 
semantics  somehow.  One  way  of  achieving  this  is  by  having  the  exact  escape  semantics 
directly  compute  the  standard  meanings  as  well  as  the  escape  meanings  of  expressions,  i.e. 
operate  on  elements  in  the  domain  Ds  X  D0.  Thus,  any  exact  escape  semantics  should 
contain  all  the  standard  meanings  and  all  the  escape  meanings.  Since  the  interpretation 
of  programs  under  the  standard  semantics  is  uncomputable,  interpretation  under  the  exact 
non-standard  escape  semantics  is  not  computable  at  compile  time.  In  fact,  from  the  point 
of  view  of  information  contents,  the  standard  semantics  can  be  considered  as  an  abstraction 
of  the  exact  escape  semantics. 

2.3  Abstract  Escape  Semantics 

The  escape  semantics  presented  in  the  last  section  specifies  exact  escape  information  about 
functions  in  a  program.  But  it  is  not  suitable  as  a  basis  for  compile-time  analysis  for  two 
reasons: 

1.  Since  conditionals  cannot  be  evaluated  at  compile-time  and  there  is  no  such  thing  as 
an  oracle  at  compile-time,  there  is  no  way  to  know  which  branch  of  a  conditional  if 
will  be  executed. 

2.  We  cannot  know  at  compile  time  exactly  which  and  how  many  elements  each  list  will 
contain.  When  some  part  of  a  list  is  taken  by  either  car  or  cdr,  there  is  no  way  to 
know  exactly  which  value  is  removed  from  the  list  and  which  values  remain  in  the  list. 

For  use  by  a  compiler,  we  need  a  suitable  escape  semantics  that  will  guarantee  termination 
and  yet  still  provide  useful  and  safe  information  with  respect  to  the  exact  escape  semantics. 
To  get  some  computable  escape  semantics,  we  need  to  somehow  abstract  or  approximate 
the  exact  escape  semantics.  In  general,  abstraction  or  approximation  of  an  exact  standard 
or  non-standard  semantics  can  be  done  by  abstracting  either  its  domains  or  its  primitive 
functions  or  both.  Generally,  there  can  be  a  range  of  possible  computable  abstractions,  all 
of  which  are  safe  but  which  may  vary  in  their  information  content  and  their  complexities. 
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Oc[c]  =  (0,  err),  c  G  , -1, 0, 1, true,  false,  nilr  hst} 
Oc[cons]  =  (0,  \x.{x^  Xy.  pair(x,  y)}) 

Oc[car]  =  (0,  Xx.  first(a)) 

Oc[cdr]  =  (0,  Aa\  second  (a;)) 

Oc[null]  =  (0,  Aa.(0,  err)) 

0e{c}envo  =  Oc[c] 

Oelxjenvo  =  env0{  a-] 

Oe\e i  +  e2 Jenv0  =  (0 ,  err)  /*  same  for  €\  —  e2  and  ei  =  e2  */ 

Oe [if  ei  then  e2  else  e3Jenv0  =  if  Oracle(ei)  then  Oe\e2\env0 

else  Oele3jenv0 

Oele^jenvo  =  (Oe[eilenn0)(2)  {Oele2Jenv0) 

Oe[lambda(a-).e]erin0  =  (V,  X y.Oe\e\env0[x  y\) 

where 

F  =  0U(  [J  (en%[z])(1))  U  (  [J  (  [J  p(1))), 

Z(zjrn°n—iist  Z£jriist  p  (eni/ol^J) 

p  in  (enr0|^])  denotes  that  p  is  an  escape  pair  in  eOT0[2], 
f  non  Ust  _  ge^  Q|'  non-hst  type  free  identifiers  in  (lambda(a).e),  and 
Fllst  =  Set  of  hst  type  free  identifiers  in  (lambda(a).e). 

Oe[letrec  xi  =  e,j; . . . ;  xn  =  en\  in  e\env0  =  OeleJenv'0 

where  env'0  =  env0[ x^  h-  Oe[ei]e7iu' , . . . ;  xn  —  Oe[en]enn'] 

Opj-Hjcr]  =  Oe\pr\nullen% 

Figure  2.3:  Escape  Semantic  Functions 


26 


1 


0 


Figure  2.4:  The  Abstract  Basic  Escape  Domain 

Abstracting  Escape  Semantic  Domains 

We  present  a  suitable,  i.e.  safe  and  computable  but  less  complete,  abstraction  of  the  exact 
escape  semantics  defined  in  the  last  section  that  allows  an  approximation  of  the  exact  escape 
behavior  to  be  found  at  compile-time. 

We  safely  approximate  the  exact  escape  semantics  by  abstracting  escape  semantic  sub- 
domains  for  list  type  expressions  and  by  approximating  escape  semantic  functions.  For 
each  expression,  its  corresponding  value  in  the  abstract  escape  semantic  domain  tells  that 
no  part  of  an  interesting  object  is  contained  in  the  value  of  the  expression  (“non-escape”), 
or  that  some  part  of  an  interesting  object  may  be  contained  in  the  value  of  the  expression 
(“possible  escape”).  The  abstract  basic  escape  domain  B0  is  a  two-element  domain  of  0  and 
1  ordered  by  0  C  1,  and  is  similar  to  the  basic  escape  domain  B0  as  shown  in  Figure  2.4. 
But,  the  interpretation  of  elements  of  B0  is  defined  differently  from  the  interpretation  of 
elements  in  B0  as  follows: 

•  1  :  Some  part  of  or  all  of  an  interesting  object  may  be  contained  in  the  value  of  the 
expression. 

•  0  :  No  part  of  any  interesting  object  is  contained  in  the  value  of  the  expression. 

Note  that  the  most  precise  information  appears  at  the  bottom  of  the  domain  and  the  least 
precise  at  top  of  the  domain.  The  0  and  1  may  be  thought  of  as  defining  sets  of  possible 
values  of  the  expressions,  and  the  domain  is  ordered  by  the  subset  ordering.  Abstraction 
of  the  escape  semantic  subdomains  for  list  type  expressions  is  done  by  representing  lists  as 
finite  objects,  i.e.  by  combining  the  escape  pairs  of  all  its  elements  into  a  single  escape  pair. 

The  abstract  escape  semantic  domain  D0  is  an  abstraction  of  Da,  and  the  domain  E0  is 
abstract  escape  environments  Ea.  They  are  defined  as  follows: 
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D0  =  /*  Abstract  escape  semantic  domain  */ 

E0  =  Id  —  D0  /*  Domain  of  abstract  escape  environments  */ 

The  abstract  escape  subdomain,  DTa  for  expressions  of  type  t  is  defined  as  follows: 

D'"lt  =  B0  X  {err}  abstract  subdomain  for  integers 

Db000‘  =  B0  X  {err}  abstract  subdomain  for  booleans 

D^2  =  B0  X  (TJ1  — >  Dl2)  abstract  subdomain  for  functions  of  type  T\  — >  r2 

Dg  llst  =  D%  abstract  subdomain  for  lists  of  type  r  list 

Note  that  the  abstract  escape  subdomain  DT0  hst  is  the  same  as  the  subdomain  DT0. 

Abstracting  Escape  Semantic  Functions 

We  now  introduce  an  abstract  escape  semantic  functions  to  give  the  syntax  the  escape 


meaning  as 

follows: 

Oc 

:  Con  - 

D0 

/*  Abstract  escape  semantic  function  for  constants  */ 

Oe 

:  Exp  - 

Eo 

D0  /*  Abstract  escape  semantic  function  for  expressions  */ 

Opr 

:  Program  — 

D0  /*  Abstract  escape  semantic  function  for  programs  */ 

As  an  abstraction  of  the  exact  escape  semantic  functions,  the  abstract  escape  semantic 
functions  are  given  in  Figure  2.5. 

The  abstract  value  of  cons  returns  a  single  escape  pair  that  is  approximating  a  list  of 
escape  pairs.  The  abstract  values  of  car  and  cdr  just  returns  their  arguments,  respectively. 
The  abstraction  for  the  conditional  expression  if  no  longer  makes  an  appeal  to  the  Oracle, 
but  rather  takes  the  least  upper  bound  of  the  escape  values  of  both  branches.  Notice  that 
the  definition  of  the  abstract  escape  semantic  function  Oe  on  the  expression  of  lambda(r).e 
is  considerably  simpler  than  the  exact  escape  semantic  function  Oe.  ehv0  is  any  abstract 
escape  environment  in  and  the  nullenv0  is  an  abstract  escape  environment  that  maps 
every  identifier  on  to  the  least  element  of  its  abstract  escape  semantic  domain. 

Safety 

The  actual  escape  property  of  the  program  that  is  being  approximated  must  imply  the 
escape  information  gathered  from  the  abstract  escape  semantics.  The  safety  of  the  abstract 
escape  semantics  means  that  the  interpretation  under  this  abstract  semantics  will  never 
produce  wrong  escape  information  with  respect  to  what  is  obtained  by  the  interpretation 
under  the  exact  escape  semantics. 
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OM  =  (0,  err),  c  G  1,  0, 1, true,  false} 

Oc[nilT  =  _LT  (  The  bottom  element  in  L>1  ) 

Oc[cons]  =  (0,Ai.(i(1),Ay.iU  y)) 

Oc[car]  =  (0,Aa.a) 

Oc[cdr]  =  (0,Aa.a) 

Oc[null]  =  (0,  Aa.(0,  err)) 

6e{c}env0  =  &M 

6e\x\envg  =  env0{xj 

6e\e i  +  e2 Jenv0  =  (0 ,err)  /*  same  for  e\  —  e2  and  e%  =  e2  */ 

Oe[if  e1  then  e2  else  e3jehv0  =  (Oe[e2]ewn0)  U  ( 0e{e3}envo ) 
Oe[eie2]efh;0  =  (Oe[ei]enw0.)(2)  {6ele2jenv0) 

<9e[lambda(a).e]ehn0  =  (V,  \y.6e\e\ehv0[x  y]) 

where 

V  -  0  U  (  |J  (enwo^j)^))  and 

z(zF 

F  =  Set  of  all  free  identifiers  in  (lambda(a).e). 

Oe[letrec  x\  =  e\\ . . . ;  xn  =  e„;  in  e\env0  =  Oe[e]efin^ 

where  ehv'0  =  {-/<r,.[a|  h-  Oe[ei]en®' , . . . ,  xn  i—  Oe[e„]e7it>£] 
Op7.[jjr]  =  6e\ prjnullenvo 

Figure  2.5:  Abstract  Escape  Semantic  Functions 
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Definition  2.2  (Non-standard  Application)  Let  NAPn  be  an  apply  operator  for  ele¬ 
ments  in  the  non-standard  semantic  domains  D0  and  Da,  defined  as  follows:  For  ep,  epi, . . . ,  epn 
G  D0  and  D0. 


NAP„(ep,  epij  . p,, ) 


def 


ep  n  =  0 

NAP,,  i(t  p{-2y  pi.tp-2,  epn)  n  >  0 


We  introduce  the  notion  of  safety  with  respect  to  escape  information  which  relates  the 
exact  escape  semantics  to  the  abstract  escape  semantics.  Let  u  and  v  be  values  of  an 
expression  e  of  type  t  or  r  list  in  the  abstract  escape  domain  D0  and  the  exact  escape 
domain  D0,  respectively.  Let  n  be  the  number  of  arguments  that  type  r  can  take  before 
returning  a  value  of  a  non-function  type.  We  say  that  the  abstract  escape  semantic  value 
u  is  a  safe  approximation  (with  respect  to  exact  escape  information)  of  the  exact  escape 
semantic  value  v  iff 


(  U  P(i))  E  NAFk(u,su  . . s*)^) 

p  in  NAPA(-u,ti,...,t*) 

for  all  k  <  n  where  s;  is  a  safe  approximation  of  t{  for  all  i  <  k. 

Theorem  2.1  (Safety)  For  any  expression  e,  and  environments  env0  and  ehv0  such  that 
for  all  y,  ehr0[y]  is  a  safe  approximation  of  envQ\y\,  Oe\e\ehv0  is  a  safe  approximation 
of  Oe\e\envQ.  Thus,  the  escape  information  obtained  by  the  exact  escape  semantics  implies 
the  escape  information  obtained  by  the  abstract  escape  semantics. 


Proof  :  We  can  prove  by  structural  induction  on  expression  e. 

I.  Base  Case: 

1.  e  =  c:  OelcjefiVo  =  Ocflc]  and  Oe\c\env0  =  0c[c].  For  c£  {. . .  ,-1,0,1.-  ■  ■  .  "true, 
false,  nil,  null  }  ,  Ocjc]  =  Oc[c]  =  (0,err).  For  c  =  cons,  it  holds  because  x±  U  X2  is 
safe  for  a  list  consisting  of  yi  and  t/2  if  xi  and  X2  are  safe  for  yi  and  t/2.  respectively.  For 
c  G  {car,  cdr  },  it  holds  because,  if  x  is  safe  for  y,  x  is  clearly  safe  for  both  firstly)  and 

second(y ). 

2.  e  =  x:  OelxJefiVo  =  ehr0[a-]  and  Of{x\env0  =  erir0[a-].  Since,  for  all  y,  efir0[y]  is 
safe  for  enr0[y],  it  clearly  holds. 

II.  Structural  Induction  Step:  Assume  that  Oe[e]ehr0  is  safe  for  Oe[e]erir0  for  expressions 
such  as  eo,  ei,  e2.  e3  an(l  en  (structural  induction  hypothesis).  Then,  we  show  that  OeleJenv0 
is  safe  for  Oe[e]enr0  for  e  =  e1  e2,  if  e i  then  e2  else  e 3,  e1e2,  lambda! a). e1,  and 
letrec  ai  =  -sh xn  =  en\  in  eo  as  follows: 
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1.  e  —  ei  +  e2:  Oe[ei  +  e2jenv0=  Oe[ei  +  e2\env0  =  (0 ,err).  Similarly,  it  holds  for  e\  —  e<i 
and  ei  =  e^. 

2.  e  =  if  ei  then  e 2  else  63:  Oe[if  ei  then  e2  else  e3]ehr0  =  Oe[e2]e'hn0  U 
Oe[e2]ehn0.  Oe[if  e 1  then  e2  else  e3]erar0  is  either  Oe[e2]enn0  or  Oe\e2\env0  depending 
on  the  standard  semantic  value  of  e\.  In  either  case,  by  the  structural  induction  hypothesis, 
Oele}env0=  Oelejenv0. 

3.  e  =  e%e2:  Oe[eie2]ehn0=  (Oe[ei]efin0)(2)  {dele2Jenv0).  Oe[eie2]enn0=  (Oe[ei]enn0)(2) 
(Oe[e2]erin0).  By  the  structural  induction  hypothesis,  (Oe[ei]ehr0)  and  (OeJe2]ehu0)  are 
safe  for  (Oe[ei]erin0)  and  (Oe[e2]erin0),  respectively.  Then,  by  the  definition  of  safe,  it 
holds. 

4.  e  =  lambda(a:).ei:  <9e[lambda(a;).e]efiu0=  {\r ,\y.Oe\e\ehv0\x  1-*  y ]).  Oe[lambda(a;).e] 

enva=  ( V ,  Ar/.Oe[e]enn0[a:  ?/]).  Since,  for  all  y,  efin0[|/]  is  safe  for  eran0[y],  we  have  that  V 

C  V.  By  the  structural  induction  hypothesis,  0  elejenv0[x  1— >  y]  is  safe  for  Oe^eJenv0[x  hh>  y], 

5.  e  =  letrec  x%  —  ej; . . . ;  xn  —  e„;  in  eo:  Oglletrec  . . . ;  =  e„;  in  eo]ehu0  = 

Oe[e0]ennp  where  ehv'0=  ehv0[xi  1—  Oe[e;]e7ir/0].  Oe[letrec  *1  =  6!;...;  xn  =  en\  in  e0] 
env0=  <9e[eo]enu'  where  env'0—  env0[xi  t— >  0e[e;]e7i©'].  Here,  env  and  env'  are  recur¬ 
sively  defined.  We  prove  that  ehv'0  is  safe  for  env'a  for  all  y  by  hxpoint  induction  on  the 
environments  env'0  and  env'0  as  follows: 

1.  Base  Case:  The  first  approximation  envj'0'  of  env'0  is  env0[xi  T].  The  first  approxi¬ 
mation  envj'0'  of  env'0  is  env0[xi  1-+  T].  Thus,  for  all  y,  envj°}\y\  is  safe  for  envj'0'  [y]. 
Then,  by  the  structural  induction  hypothesis,  O  e\eo\env'0.  is  safe  for  Oeleolenv'0. 

2.  Fixpoint  Induction  Step:  Assume  that,  for  some  fixed  k  >  0,  the  kth  approxima¬ 

tion  envjk^\y\  is  safe  for  envjk^\y\  for  all  y.  (fixpoint  induction  hypothesis)  Then, 
The  (k  +  l)th  approximation  cnvjk '  l!  is  ehv0[xi  Oe\e^\envJk^],  and  envj'k+1'  is 
env0[xi  Oeleijenvo^'].  By  the  structural  induction  hypothesis,  Oe\ei\ehvJk^  is  safe 
for  Oe\ej\envok\  Thus,  for  all  y,  ehv'JkJrl\y\  is  safe  for  [$/].  Then,  by  the 

structural  induction  hypothesis,  Oeleojenv'0  is  safe  for  Oe[eo]enr'. 

□ 


Termination 

A  compiler  should  terminate  on  every  valid  program.  In  order  for  any  compiler  which  uses  an 
analysis  based  on  the  abstract  escape  semantics  to  be  effective,  the  interpretation  under  the 
abstract  escape  semantics  must  also  be  effective.  The  effectiveness  of  interpretation  under 
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the  abstract  escape  semantics  means  that  it  terminates  on  every  valid  program.  When  the 
abstract  version  of  a  function  derived  by  the  abstract  escape  semantics  is  non-recursive,  ter¬ 
mination  is  guaranteed.  Recursive  functions,  however,  derive  recursively  defined  functions 
as  their  abstract  versions.  From  the  fixed  point  theorem  of  domain  theory,  the  recursive 
function  is  given  by  the  least  fixed  point  of  the  corresponding  higher-order  functional.  That 
is,  for  the  function 

/  =  F(f) 

where  /  is  of  type  r  and  F  is  a  functional  corresponding  to  the  body  of  /,  the  meaning  of 
/  is  defined  to  be  the  least  function  satisfying  the  above  equation  and  the  least  hxpoint  / 
can  be  found  as  follows: 

/=  \_\FiM 

i—>  oo 

where  F°(x)  —  x  and  F*(x)  =  F(Ft~1(x ))  and  _LT  is  the  bottom  element  of  the  domain  of 
type  r,  i.e.  DT . 

Theorem  2.2  (Termination)  For  any  (finite)  program  pr  £  Program,  is  com¬ 

putable,  i.e.  always  terminates  in  finite  number  of  steps.  Thus,  interpretation  of  pr  under 
the  abstract  escape  semantics  terminates. 

Proof  :  We  can  prove  that  the  interpretation  of  a  program  under  the  abstract  escape 
semantics  will  terminate  by  showing  that  the  least  fixed  point  of  any  functional  in  the 
abstract  escape  semantic  domain  can  be  computed  in  a  finite  number  of  steps.  That  is,  for 
all  functions  defined  according  to  the  above  equation,  there  must  exist  some  j  such  that 

Fk(±T)  =  F~(l.j ) 

for  all  k  >  j.  A  way  of  showing  that  there  exists  such  a  j  is  to  show  that  every  functional  F 
must  be  monotonic  and  that  the  fixpoint  iteration  is  performed  over  a  finite  domain.  First, 
every  functional  over  escape  pairs  defined  in  the  abstract  escape  semantics  is  composed  of 
monotonic  operators  and  the  least  upper  bound  operator  U,  which  is  monotonic.  Thus, 
every  functional  in  the  abstract  escape  semantics  is  monotonic.  Second,  Db0  is  finite  for 
each  base  type  b.  Dfi^T2  is  also  finite  whenever  Dfi-  and  ZF2  are  finite,  each  domain  Df 
for  each  type  r  is  finite.  By  induction,  then,  in  a  strongly  typed  system  where  all  types  are 
finite,  all  DT  are  finite.  When  finding  the  least  fixpoint  of  a  function  of  type  r,  we  need 
only  search  over  the  subdomain  D)  of  D0  and  D)  is  finite.  Thus  the  least  fixpoint  can 
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be  computed  in  a  finite  number  of  steps.  Hence  any  analysis  based  on  the  abstract  escape 
semantics  is  guaranteed  to  terminate  at  compile-time.  □ 

For  example,  consider  the  following  function  f  of  type  int  — >  int  — >  int  defined  by 

f  x  y  =  if  (x=0)  then  y  else  f  (x-1)  (x+y) 

The  corresponding  function  /  under  the  abstract  escape  semantics  is  described  by 

/  =  (0,  Xx.(x^:  At/.Oe[if  (x=0)  then  y  else  f  (x-1)  (x+y)][x  h->  x,  y  y])) 

=  (0,  Ax.(a;(1),  A y.y  U  (/(2)(0,  err))f2)(0,  err}}}. 

Since  /  is  recursive,  /  is  the  least  hxpoint  of  the  functional  F  of  type  ( int  —  int  —  int ) 
— »  int  — »  int  — >  int  dehned  by 

F  =  A/.(0,  Aa-.(a-(1),  Ay.y  U  (/(2)(0,  err))(2)(0,  err)}}. 

Then,  the  least  hxpoint  is  found  by  the  following  hxpoint  iteration: 

/(°)  =  F(± 

int— tint— > int  ) 

=  (0,  Aa.(a(1),  Aj/.yU  (T 

int-tint^-in  t(2)  (0,  ear))(2)(0,  err})) 

=  (0,  Aa.(a(1),  Ay.j/U  T 

int-^in  t(2)(0j  err))) 

=  (0,  Aa.(a(1),  Ay.yU  ±tnt)) 

=  (0,  Aa.(a(1),A y.y}} 

/l1)  =  F(f(° )) 

=  (0,  Aa.(a(1),  Ay.y  U  (((0,  Aa.(a(1),  Ay.y)))(2)(0,  err))(2)(0,  err))) 

=  (0,  Aa.(a(1),  A  y.y  U  (((0,  Ay.|/))f2)(0,  err))) 

=  (0,  Aa.(a(!p  Xy.y  U  (0,  err) 

=  (0,  Aa.(a(1),A y.y)) 

Since  /(°)  =  a  hxpoint  has  b  een  found.  Thus,  /  =  (0,  Aa^a^p  Xy.y)). 

2.4  Escapement  Testing 

Since  interpretation  under  the  abstract  escape  semantics  is  guaranteed  to  terminate,  the 
abstract  escape  semantics  can  be  used  as  a  basis  to  infer  the  escape  information  for  functions 
in  a  program  at  compile-time.  We  describe  escape  testing  algorithms  including  a  global 
escape  test  and  a  local  escape  test,  in  which  the  abstract  functions  are  used  to  detect  static 
information  about  the  escape  properties  of  the  corresponding  functions  in  a  program. 
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We  perform  the  escape  test  on  each  argument  of  a  function  call  separately.  Thus,  at 
any  time  we  are  only  interested  in  whether  or  not  a  particular  single  object  escapes.  Other 
objects  may  escape  in  the  result  of  a  function  call,  but  are  ignored  by  our  analysis.  If  a 
function  has  n  parameters,  then  escape  test  will  be  performed  n  times,  each  time  treating 
a  different  parameter  as  interesting. 

Global  Escape  Test 

We  describe  a  global  escape  test  which  provides  the  global  escape  information  about  each 
function  in  a  program  that  holds  true  for  every  possible  application  of  the  function.  The 
global  escape  test  is  performed  only  on  a  function  definition,  and  thus  gives  general  infor¬ 
mation  about  the  escape  property  of  that  function.  To  do  so,  we  have  to  apply  the  escape 
semantic  value  of  a  function  to  arguments  that  cause  the  greatest  escapement  possible. 

Definition  2.3  (Worst-case  Escape  Function)  For  each  non-list  type  r,  we  define  the 
abstract  function  WT  that  corresponds  to  a  function  from  which  every  argument  escapes. 

m 

Aa:2.(a:1-(i)  □  x2(1), . . . ,  A.rm.(  [J  xl(J),  ( /t)  . . .))  m>  1 

p= i 

err  m  —  0 

where  m  is  the  number  of  arguments  that  a  function  of  type  r  can  take  before  returning  a 
primitive  value.  For  each  fist  type  of  r  list,  WT  hst  is  defined  to  be  WT . 

Given  a  function  /  ii  i2  ...  i„  =  bodyj  of  arity  n,  the  position  i  of  an  interesting 
parameter,  and  an  abstract  escape  semantic  environment  env0  mapping  /  to  an  element  of 
1)0,  the  global  escape  test  function  G .escape?  determines  whether  the  ith  parameter  of  / 
could  possibly  escape  /  or  not.  It  is  defined  as  follows: 

G .escape? (/,  i,  ehv0)  =  (6e{f  x1  . . .  xnJ  ehv0[xt  >— 

where 

yt  —  (l,IFn),  /*  The  ith  parameter  is  an  interesting  object  */ 
for  all  j  <  n  and  j  y?  i, 

yj  =  (0,  WTj),  /*  Other  parameters  are  not  interesting  objects  */ 

and  r,t  is  the  type  of  the  ith  parameter  of  /.  Only  the  ith  argument  to  /  is  an  interesting 
object  and  other  arguments  are  not  interesting  objects.  The  functional  part  of  each  argu¬ 
ment  causes  maximal  escapement.  Thus,  from  the  result  of  the  global  escape  test  function, 
we  can  conclude  the  following: 


WT  d=  { 
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•  If  G ^escape? (/,  i,  env0)  =  0  then  we  conclude  that  in  any  possible  application  of  /  to 
n  arguments,  the  ith  argument  does  not  escape  /. 

•  If  G_escape?(/,  i,  env0)  =  1  then  it  means  that  in  some  possible  application  of  /  to  n 
arguments,  the  ith  argument  could  escape  /. 

Local  Escape  Test 

Generally,  we  would  like  to  know  if  an  argument  escapes  from  a  particular  call  to  a  function. 
This  depends  on  the  values  of  the  arguments  of  that  call.  We  describe  a  local  escape  analysis 
which  provides  escape  information  of  a  function  in  a  particular  context.  The  local  escape 
test  determines  the  escape  behavior  of  a  particular  function  call,  and  thus  yields  more 
specific  results  than  the  global  escape  test.  Given  a  function  f  x i  x%  ...  xn  =  bodyj  of 
arity  n  in  an  application  f  e j  ...  en ,  the  position  i  of  an  interesting  parameter,  and  an 
abstract  escape  semantic  environment  env0  mapping  /  and  the  free  identifiers  within  e\ 
through  en  to  elements  of  Da,  the  local  escape  test  function  L_escape?  determines  whether 
the  ith  parameter  of  /  could  escape  /  during  the  evaluation  of  /  ei  ...  en.  It  is  defined  as 
follows: 

L_escape?  (/,  i,  e1? .  ,.,en,env0)  =  (<3e|[/  x1  . . .  ij  ehv0[xi  >-+  v/£J  )(J , 

where 

yi  —  (l,(<9e[e!']  env0){2))i  /*  The  ith  parameter  is  an  interesting  object  */ 
and  for  all  j  <  n  and  j  ^  i, 

y j  =  (0,  (Oe[ej]  ehv0)( 2)).  /*  Other  parameters  are  not  interesting  objects  */ 

Only  the  ith  parameter  is  an  interesting  object  and  other  parameters  are  not  interesting 
objects.  The  functional  part  of  each  argument  is  the  functional  behavior  of  each  expression 
ej.  Then,  from  the  result  of  the  local  escape  test  function,  we  can  conclude  the  following: 

•  If  L_escape?  (  /.  i,  (-y. . . , ,  e„,  env0)  =  0  then  we  conclude  that  the  ith  argument  does  not 
escape  /  in  the  particular  application  of  /  to  ei  through  en. 

•  If  L_escape?(/,  i,  ei, . . . ,  en,  env0)  =  1  then  the  ith  argument  could  escape  /  in  the 
particular  application  of  /  to  e\  through  en. 
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Examples 


As  an  example,  consider  a  program  defined  as  follows: 

letrec  g  a  b  =  if  (a  <  b)  then  0  else  a; 

h  c  d  =  if  (c  <  d)  then  d  else  0; 

map  f  1  =  if  (null  1)  then  nil 

else  cons  (f  (car  1))  (map  f  (cdr  1)); 

in  ...  (map  (g  3)  [1,3,5])  ...  (map  (h  3)  [1,3,5])  ... 

We  assume  that  the  type  of  each  function  is  given  by 

g  :  ini  — »  ini  — >  int 
h  :  int  — *  int  — ►  int 

map  :  ( int  — >  int )  — >  int  list  int  list. 

Then,  the  abstractions  g ,  h,  and  map  of  g,  h,  and  map  under  the  abstract  escape  semantics 
are  defined  as  follows: 

g  =  (0,  Aa.(a^),  Xb.((0,  err)  U  a))} 

=  (0,  Xa.(a^,  Xb.a)) 

h  =  (0,  Xd.((0,  err)  U  d))) 

=  (0,  Ac.(c^),  Xd.d)) 

map  =  <0,  A/.(/(1),  XL 

(0,  err )  U  (/  l)  U  ( (mop(2)  /)(2)  I) 

Since  map  is  defined  recursively,  the  meaning  of  map  is  found  by  fixpoint  iteration  as  follows: 
map (°)  /  l  =  (0,  err) 

mapW  f  l  =  (0,  err )  U  (/(2)  /)  U  (( map /)(2)  I) 

=  (0,  err)  U  (/(2)  l)  U  (0,  err) 

=  /( 2)  l 

mapW  /  l  =  (0,  err )  U  (  /(2)  /)  U  ((mop^  /)(2)  1) 

=  (0,  err)  U  (/(2)  /)  U  (  /(2)  I) 

=  1(2)  l 

Since  map W  =  map(2\  we  have  that  mop  =  (0,  A f-(f(i),  Xl.f^2)  0)-  Let  be  an  abstract 
escape  environment  defined  as  env0  =  [g  i— >  g,  hw  h,map  map]. 
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Global  Escape  Information 

To  find  the  global  (i.e.  worst-case)  escape  property  of  map,  we  apply  the  global  escape  test 
function  G .escape?. 

G .escape? (map,  1,  ehv0)  -  (Oe[map  f  l] env'0)^  =  0 

where 

env'0  -  ehv0[ f  ^  (1,^^'),^  (0,ITmi^)], 

}ytnt-*mt  _  Xx.(x^,err),  Wmt  hst  =  err. 

Thus,  we  can  conclude  that  the  first  parameter  f  of  the  function  map  can  never  escape  map 
globally.  And, 

G .escape? (map,  2,  ehv0)  —  (Oe[map  f  l] env'o)  ^  =  1 

where 

env’o  -  env0[ f  ^  (0,  Wint^mt),  1  ^  <1,  VT’"* "**)], 

=  Ax.(xfl),err),  VEin* =  err. 

This  means  that  the  second  parameter  1  of  the  function  map  could  escape  in  some  situation. 
Thus,  we  cannot  say  that  1  never  escape  map  globally. 

Local  Escape  Information 

To  determine  the  local  escape  property  of  map  in  a  particular  context,  we  apply  the  local 
escape  test  function  L_escape?. 

L_escape?(map.  2,  (g  3),  [1,  3,  5],  envp)  =  (Oe[map  f  l] env'0)^  =  0 

where 

env'o  =  env0  [f  i->  (0,(5(2)(0,err))(2)),l  h-  {l, err)]. 

Thus,  we  can  conclude  that  the  second  parameter  1  of  the  function  map  does  not  escape 
locally  in  (map  (g  3)  [1,3,5]). 

L_escape?(map,  2,  (h  3),  [1,  3,  5],  envp)  =  (Oe[map  f  l] env'0)^  =  1 

where 

env'o  =  env0[ f  i->  (0,  (/i(2)(0, err))(2)),  1  (l,err)]. 

So,  we  can  conclude  that  the  second  parameter  1  of  the  function  map  does  escape  locally  in 
(map  (h  3)  [1,3,5]). 
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2.5  Improving  Precision  of  Escapement 


In  the  abstract  escape  semantics  described  in  the  previous  section,  a  list  is  treated  as  a 
single  object.  Once  an  interesting  object  is  put  in  a  list,  we  have  assume  that  the  object 
remains  in  the  list.  Thus,  no  matter  how  many  times  cdr  is  applied  to  the  list,  we  assume 
that  the  interesting  object  remains.  Furthermore,  any  time  car  is  applied  to  the  list,  we 
assume  that  the  interesting  object  might  be  contained  in  the  result. 

Consider,  for  example,  the  following  functions: 

letrec  f  x  y  =  car (cons  x  (cons  y  nil)); 

g  x  y  =  cdr (cons  x  (cons  y  nil)); 
in  ...  cons  (f  1  2)  (g  1  2)  ... 

where  f  is  of  type  int  — >  int  — >  int  and  g  is  of  type  ini  — >  ini  — >  int  list.  Under  the  abstract 
escape  semantics,  the  definitions  of  values  /  and  g  of  f  and  g  are  the  same. 

/  =  (0,  Xx.(x^  Xy.x  U  (y  U  (0,  err)))) 

=  (0,Xx.(x^,Xy.xUy)) 

=  9 

From  the  escape  analysis  based  on  the  abstract  escape  semantics,  we  conclude  only  that 
both  x  and  y  could  escape  f  and  g.  In  fact,  for  the  function  f ,  only  the  first  parameter  x 
escapes  f ,  but  the  second  parameter  y  never  escapes  f .  Similarly,  only  the  second  parameter 
y  actually  escapes  g,  but  the  first  parameter  x  never  escapes  g. 

In  this  section,  we  present  a  method  for  improving  the  precision  of  escape  information 
that  is  obtainable  through  the  escape  analysis  using  the  position  information  of  interesting 
objects  in  a  list  structure. 

2.5.1  Positions  of  a  List 

The  information  about  where  an  interesting  object  occurs  in  a  list  will  provide  a  more 
accurate  approximation  of  escapement.  We  describe  how  to  include  information  about 
object’s  position  within  a  list  in  the  escape  semantics,  in  order  to  keep  track  (approximately) 
of  what  position) first  element,  second  element,  etc.)  in  the  top  spine  of  the  list  an  object 
might  occur  first.  The  notion  of  position  in  a  list  is  shown  in  Figure  2.6. 

Definition  2.4  (Positions  of  a  List)  An  object  is  said  to  be  at  the  position  of  i  in  a  list 
L  if  some  part  of  or  all  of  the  object  only  resides  in  the  sublist  of  L  whose  root  cell  is 
specified  by  cdr*  L  for  some  i  >  0,  i.e.  In  other  word,  no  part  of  the  object  is  contained  in 
the  first  (i  —  1)  positions  of  L. 


38 


Position=0 


Position  =  l 


Position=2 


Position=3 


Figure  2.6:  Positions  of  a  List 

Since  no  finite  bound  on  the  length  of  lists  can  be  computed  at  compile  time,  we  impose 
a  bound  on  the  positions  in  the  list  that  we  are  willing  to  keep  track  of.  Beyond  this  bound, 
we  assume  that  the  object  remains  in  the  list. 

2.5.2  Improved  Abstract  Escape  Semantics 

We  present  another  safe  and  computable  abstraction  of  the  exact  escape  semantics  that 
gives  escape  information  with  more  precision  than  the  abstract  escape  semantics  previously 
described. 

Improved  Abstract  Escape  Domains 

The  value  of  each  expression  in  the  improved  escape  semantic  domain  indicates  either  that 
no  part  of  an  interesting  object  is  contained  in  the  value  of  the  expression  ( “non-escape” ) ,  or 
that  some  part  of  an  interesting  object  may  be  contained  at  some  position  in  the  value  of  the 
expression  (“possible  escape  and  where”).  The  improved  abstraction  of  the  exact  escape 
semantics  is  done  by  extending  the  basic  abstract  escape  domain  to  including  position 
information.  The  basic  improved  abstract  escape  domain,  B0 ,  for  some  fixed  p  is  a  (p+  2)- 
element  domain  of  pairs  as  shown  in  Figure  2.7.  The  ordering  on  pairs  in  B0  is  defined  as 
follows: 

(0,0)C(l,p)C(l,p-l)C..,C(l,l)C(l,0) 

The  interpretation  of  elements  of  B0  is  defined  as  follows: 
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(1,0) 


<!j P  —  !) 

(!,  p) 

(0,0) 


Figure  2.7:  Tire  Improved  Abstract  Basic  Escape  Domain 


•  (l,Je)  :  Some  part  of  or  all  of  an  interesting  object  may  be  contained  in  the  value  of 
the  expression  only  at  a  position  greater  than  or  equal  to  >  k.  (not  at  a  position  less 
than  k ) 

•  (0,  0)  :  No  part  of  any  interesting  object  is  contained  in  the  value  of  the  expression. 


The  improved  abstract  escape  domain  D0  is  an  improved  abstraction  of  D0,  and  the  im¬ 
proved  abstract  escape  environment  E0  is  a  domain  of  functions  mapping  identifiers  to  their 
abstract  escape  meanings.  They  are  defined  as  follows: 

D0  =  ^ Dl  /*  Improved  abstract  escape  semantic  domain  */ 

E0  =  Id  D0  /*  Domain  of  improved  abstract  escape  environments  */ 


The  improved  abstract  escape  subdomain  DT0  for  expression  of  type  r  is  defined  as  follows: 


jnint 

jjbool 


jjt  list 


B0  X  {err}  improved  abstract  subdomain  for  integers 

B0  X  {err}  improved  abstract  subdomain  for  booleans 

B0  X  (Dl1  —r  Dl2)  improved  abstract  subdomain  for  functions 

Dl  improved  abstract  subdomain  for  lists 


Improved  Abstract  Escape  Semantic  Functions 

We  now  introduce  improved  abstract  escape  semantic  functions  as  follows: 
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OM 

Oc[nilr  tist} 
Oc[cons] 


Oc[car] 

Oc[cdr] 

Oc[null] 


((0,  0),  err),  c  £  — 1,  0,  1, . . . ,  true,  false} 

_Lr  (  The  bottom  element  in  Df  ) 

((0,  0),  Aa\(a-(1),  Aj/.push(a,  y))) 
where 

push(a,  y)  =  if  =  1)  then  ((l,0),a(2)  U  j/(2)) 

elseif  (^(i)  =  1)  then  ((1,  min(?/(1)(2)  +  l,p)),a(2)  U  j/(2)) 
else  ((0,0),a(2)  U  t/(2)) 

((0,  0),  Aa.  pick(a)) 

where  pick(^)  =  if  (^(i)(2)  >  0)  then  ((0,0),  a(2))  else  z 
((0,  0),  Aa.  rest(a)) 

where  resl(r)  =  ((z(n.  ina.x(r(2)  -  l,0)),z(2)) 

((0,0),  Aa.((0, 0),  err) 


Figure  2.8:  Improved  Abstract  Escape  Semantic  Functions 

Oc  :  Con  D0  /*  Improved  semantic  function  for  constants  */ 

Oe  :  Exp  — >  E0  D0  /*  Improved  semantic  function  for  expressions  */ 

Opr  :  Program  — >  D0  /*  Improved  semantic  function  for  programs  */ 

The  improved  abstract  escape  semantic  functions  are  given  in  Figure  2.8  and  Figure  2.9. 

The  improved  abstract  value  of  cons  takes  two  arguments,  and  returns  an  improved 
escape  pair  of  their  least  upper  bound  by  updating  the  position  information  of  an  interesting 
object  in  the  result  list.  The  improved  abstract  value  of  car  returns  its  argument  according 
to  the  position  of  an  interesting  object.  The  improved  abstract  value  of  cdr  also  updates 
the  position  information  appropriately.  Note  that  the  improved  abstract  escape  semantic 
function  Oc  for  cons,  car  and  cdr  provides  more  precise  escape  information  than  the 
abstract  escape  semantic  function  0C.  ehv0  is  an  improved  abstract  escape  environment  in 
Ea,  and  nullenv0  is  an  improved  abstract  escape  environment  that  maps  every  identifier  on 
to  the  least  element  of  its  improved  abstract  escape  semantic  domain. 


Safety  and  Termination 

To  show  that  the  improved  abstract  escape  semantics  will  never  produce  wrong  escape 
information  with  respect  to  the  exact  escape  semantics,  we  introduce  a  notion  of  safety  with 
respect  to  exact  escape  information  that  relates  the  improved  abstract  escape  semantics  with 
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OelcJenv0  =  Oc[c\ 

de{x}env0  =  env  0\  a-] 

Oe\e i  +  e2 Jehv0  =  ((0,0),  err)  /*  same  for  e\  —  e2  and  e\  —  e2  */ 

Oejif  ei  then  e2  else  e3}env0  =  (Oe[e2]en»0)  U  (OeHe3]en%) 

Oe[eie2]enr0  =  (<5e[ei]erir0)(2)  {Oele2}env0) 

Oe[lambda(a:).e]enr0  =  (V,  \y .0 e\e\env 0\x  hh>  y]) 

where 

V  -  (0,  0)  U  ( |J  (enroll )(1))  and 

z£.F 

F  =  Set  of  all  free  identifiers  in  (lambda(s).e). 

Oe[letrec  x^  —  e\\ . . . ;  xn  =  en\  in  e\env0  =  OeleJehv'0 

where  env'0  =  env0[x1  ^  <5e[ei]eh^, . . . ,  xn  i->  Oe[e„]ehn(] 

0Prl2)rJ  =  Oe\pr\nullenv0 

Figure  2.9:  Improved  Abstract  Escape  Semantic  Functions 

the  exact  escape  semantics.  Let  u  and  v  be  values  of  an  expression  e  of  type  r  or  r  list  in 
the  improved  abstract  escape  domain  D0  and  the  exact  escape  domain  D0 ,  respectively.  Let 
n  be  the  number  of  arguments  that  the  type  r  can  take  before  returning  a  value  of  primitive 
type.  We  say  that  the  improved  abstract  escape  semantic  value  u  is  a  safe  approximation 
(with  respect  to  exact  escape  information)  for  the  exact  escape  semantic  value  v  iff 

(  U  P(i))  E  (NAP^(u,51,...,s*))(1)(1) 

p  in  NAPA(-u,ii,...,ffc) 

and 


(MINp hl  NAP* (u,ti,...,tA)&p(1)=i Position  of  p)  >  (NAPjt(«,  sa, . . . ,  ^))(1)(2) 
for  all  k  <  n  where  Si  is  a  safe  approximation  for  ti  for  all  i  <  k. 

Theorem  2.3  (Safety)  For  any  expression  e,  and  environments  env0  and  env0  such  that 
for  all  y,  ehn0[j/]  is  safe  for  enva[y\,  Oe\e\env0  is  safe  (with  respect  to  escape  information) 
for  0e\e\envo. 

Proof  :  We  can  prove  by  structural  induction  on  expression  e. 

I.  Base  Case: 
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1.  e  =  c:  Oe\c\envQ  =  Oc[c]  and  Oe\c\env0  =  Oc[c].  For  c  G  {. . .  ,-l  ,0 , 1 , .  .  . true , 
false,  nil,  null  }  ,  Oc[c]  =  Oc[c]  and  thus  it  clearly  holds.  For  c  =  cons,  it  holds 
because,  if  x\  and  x<i  are  safe  for  y\  and  y^,  respectively,  push(a:,y)  is  also  safe  for  a  list 
consisting  of  yi  and  3/2 -  If  holds  for  c  =  car,  cdr,  because  if  x  is  safe  for  y  then  pick(r)  is 
safe  for  firstly)  and  rest  (a;)  is  safe  for  second(y). 

2.  e  —  x:  OelxJenv0  —  ehr0[r]  and  Oe[a-]enr0  =  erar0[a].  Since  for  all  y  enr0[y]  is  safe 
for  env0\y\,  it  clearly  holds. 

(II)  Structural  Induction  Step:  Assume  that  Oe|e]ehr0  is  safe  for  Oe\e\env0  for  expressions 
such  as  eo,  ei,  62,  e-z  and  en.  (structural  induction  hypothesis)  Then,  we  show  that  Oe[e]erir0 
is  safe  for  Oe[e\env0  for  e  =  e\  +  if  e\  then  e2  else  e^,  lambda(a).e,  and 

letrec  x\  =  ej-; , . . ;  xn  =  en ;  in  eo-  This  can  be  proved  in  an  exactly  similar  way  to  the 
proof  of  safety  of  the  abstract  escape  semantics.  □ 

The  effectiveness  of  interpretation  under  the  improved  abstract  escape  semantics  means 
that  it  terminates  on  every  valid  program  at  compile-time. 

Theorem  2.4  (Termination)  For  any  (finite)  program  pr  G  Program,  Opr\pr\  are  com¬ 
putable,  i.e.  always  terminates  in  finite  number  of  steps. 

Proof  :  Every  functional  in  the  improved  escape  domain  that  is  defined  through  the 
abstract  improved  escape  semantic  functions  is  composed  of  the  operators  such  as  the  least 
upper  bound  operator  U,  push,  pick,  and  rest,  pick  and  rest  are  monotonic  operators.  Since 
the  composition  of  monotonic  functions  is  also  monotonic,  every  functional  is  monotonic. 
Furthermore,  each  subdomain  DT  is  finite.  □ 

Precision  Improvement 

The  precision  improvement  of  the  improved  abstract  escape  semantics  over  the  abstract 
escape  semantics  means  that  the  escape  information  obtained  by  the  improved  abstract 
escape  semantics  always  implies  that  obtained  by  the  abstract  escape  semantics,  but  not 
always  vice-versa. 

Theorem  2.5  (Precision  Improvement)  The  abstract  escape  semantics  is  equivalent  in 
its  information  content  to  the  improved  abstract  escape  semantics  with  p  =  0.  Thus,  the  im¬ 
proved  abstract  escape  semantics  with  some  p  >  0  provides  more  precise  escape  information 
than  the  abstract  escape  semantics. 

Proof  :  We  introduce  the  notion  of  equivalence  with  respect  to  escapement  information 
content  which  relates  the  abstract  escape  semantics  to  the  improved  abstract  escape  sernan- 
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tics  with  p  =  0.  Let  u  and  v  be  values  of  an  expression  e  of  type  r  in  D0  and  D0  with  p  =  0, 
respectively.  Let  n  be  the  number  of  arguments  that  the  type  t  can  take  before  returning 
a  value  of  primitive  type.  We  say  that  u  is  equivalent  (with  respect  to  escape  information) 
to  v  iff 

( —  ( NAP^  (h.  . . . , 

for  all  k  <  n  where  Si  is  equivalent  to  E  for  all  i  <  k.  Then,  for  all  expression  e  and 
environments  ehv0  and  env0  withp  =  0  such  that  for  all  y,  env0[y]  is  semantically  equivalent 
(with  respect  to  escape  information)  to  enu0[j/]  with  p  =  0,  we  have  that  Oe\e\env0  is 
semantically  equivalent  to  Oe[e]erin0  with  p  =  0.  This  can  be  proved  by  structural  and 
fixpoint  inductions. 

We  introduce  the  notion  of  improvement  with  respect  to  escapement  information  content 
which  relates  the  improved  abstract  escape  semantics  with  p  >  0  to  the  improved  abstract 
escape  semantics  with  p  =  0.  Let  u  and  v  be  values  of  an  expression  e  of  type  r  in  D0  with 
p  >  0  and  D0  with  p  =  0,  respectively.  Let  n  be  the  number  of  arguments  that  the  type  r 
can  take  before  returning  a  value  of  primitive  type.  We  say  that  u  is  improved  (with  respect 
to  escape  information)  over  v  iff 

(NAPfc(w,  si, . .  .  ,s*))(1)(1)  E  (NAFk{v,t1: . .  ■ ,  4))(i)(i) 

and 


(NAPfc(w,  Si, . .  .,s*))(1)(2)  E  (NAPfc(ij, <i,  •  •  -  ,4))(1)(2)  =  0 

for  all  k  <  n  where  .s,  is  improved  over  t{  for  all  i  <  k.  Then,  for  all  expression  e  and 
environments  env0  with  p  >  0  and  env0  with  p  =  0  such  that  for  all  y,  efit>0[t/]  with  p  >  0 
is  improved  over  enu0[j/J  with  p  =  0,  we  have  that  entJ0[j/]  with  p  >  0  is  improved  over 
OeleJenv0  with  p  =  0.  This  can  be  proved  by  structural  and  fixpoint  inductions.  □ 

The  relationship  among  the  standard  semantics  (SS),  the  non-standard  exact  escape  seman¬ 
tics  (ES),  the  abstract  escape  semantics  (AES)  and  the  improved  abstract  escape  semantics 
(IAES)  is  shown  in  Figure  2.10. 

2.5.3  Improved  Escapement  Testing 

We  describe  global  and  local  escape  testing  algorithms  based  on  the  improved  abstract 
escape  semantics. 
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AES  “information  content” 


Figure  2.10:  Relationship  among  Standard  and  Escape  semantics 

Improved  Global  Escape  Test 

Given  a  function  /  x-^  x?  ...  xn  =  bodyj  of  arity  n.  the  position  i  of  an  interesting 
parameter,  and  an  improved  abstract  escape  semantic  environment  env0  mapping  /  to 
an  element  of  D 0 ,  the  improved  global  escape  test  function  GJescape?  which  determines 
whether  the  ith  parameter  of  /  could  possibly  escape  /  in  any  application  of  /  or  not  is 
defined  as  follows: 

GJescape? (/,  i,  env0)  =  ( Oe[f  a1!  ...  a„]  env0[xt  h->  f/*])(i)(i) 

where 

yi  =  ((1,  0),  fFr*),  /*  The  ith  parameter  is  an  interesting  object  */ 
and  for  all  j  <  n  and  j  /  i. 

y:i  =  ((0,  0),  WTi),  /*  Other  parameters  are  not  interesting  objects  */ 

and  Tt  is  the  type  of  the  ith  parameter  of  /.  Only  the  ith  argument  to  /  is  an  interesting 
object  and  other  arguments  are  not  interesting  objects.  Since  the  whole  ith  argument  is 
interesting,  its  position  value  is  set  0.  The  result  of  the  global  improved  escape  test  function 
is  interpreted  as  follows: 

•  If  GJescape? (/,  i,env0)  =  0  then  we  conclude  that  the  ith  argument  does  not  escape 
/  in  any  possible  application  of  /  to  n  arguments. 

•  If  GJescape?(/,  i,  envQ)  =  1  then  we  cannot  say  that  the  ith  argument  does  not  escape 
/  in  any  possible  application  of  /  to  n  arguments. 
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Improved  Local  Escape  Test 

Given  a  function  f  x  1X2  . . .  xn  =  bodyf  of  arity  n  in  an  application  context  f  e%  ...  e„, 
the  position  i  of  an  interesting  parameter,  and  an  improved  abstract  escape  semantic  envi¬ 
ronment  env0  mapping  /  and  the  free  identifiers  within  e\  through  en  to  elements  of  D0 ,  the 
improved  local  escape  test  function  LJescape?  which  determines  whether  the  ith  parameter 
of  /  could  escape  /  locally  in  the  evaluation  of  /  ej  . . .  en  is  defined  as  follows: 

LJescape?  (/,  i,  e1; . . . ,  e„,  env0)  -  (Oe{f  x  1  ...  xnJ  env0[xt  ;</,])(  i)(  1) 

where 

yi  =  ((1,  0),  (Oe[eJ  en%)(2))  /*  The  ith  parameter  is  an  interesting  object  */ 
and  for  all  j  <  n  and  j  7?  i. 

y:i  —  ((0,0),  enr0)(2))-  /*  Other  parameters  are  not  interesting  objects  *j 

The  result  of  the  local  improved  escape  test  function  is  interpreted  as  follows: 

•  If  LJescape?(/,  *,  ej, . . . ,  fin,  env0)  =  0  then  we  conclude  that  the  ith  argument  does 
not  escape  /  in  the  particular  application  of  /  to  e\  through  en. 

•  If  LJescape?(/,  *,  ■  ■  ■ ,  e-n-  env0)  =  1  then  we  cannot  say  that  the  ith  argument  does 

not  escape  /  in  the  particular  application  of  /  to  ej  through  en. 

Examples 

As  an  example,  consider  the  functions  given  before: 

letrec 

f  x  y  =  car (cons  x  (cons  y  nil)); 
g  x  y  =  cdr(cons  x  (cons  y  nil)); 
in  ... 

where  f  is  of  type  ini  — >  ini  —  ini  and  g  is  of  type  ini  — >  ini  —  ini  list.  Under  the  improved 
abstract  escape  semantics,  the  definitions  of  the  values  /  and  g  of  f  and  g  are  expressed  as 
follows: 


/  =  ((0,0),  Az.(z(1),  Ay.pick(push(z,push(r/,  ((0,  0),  err)))))) 

g  =  ((0,  0),  Aa\(z(1),  Ay.rest(push(a,  push(y,  ((0,  0),  err)))))) 

Let  env0  be  defined  as  env0  =  [f  ^  /,  g  •->  9] 
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G  Jescape? (f,  2,  enva)  =  (Oe[f  x  y]enu'0  )(!)(!)  =  0 

where  env'0  =  env0[x  hh>  ((0,  0),  err),  y  h- ►  ((1,  0),  err)].  Thus,  we  can  conclude  that  the 
second  parameter  y  of  f  does  not  escape  f  globally.  Similarly, 

G Jescape? (g,  1,  enva)  =  (Oe[g  x  y]erir'0)(1)(1)  =  0 

where  env'0  -  env0[x  ((1,  0),  err),  y  ((0,  0),  err)].  Thus,  we  can  conclude  that  the  first 
parameter  x  of  g  does  not  escape  g  globally. 

2.6  Complexity  of  Escape  Analysis 

The  abstract  interpretation  framework  for  the  escape  analysis  that  deals  with  higher-order 
functional  languages  with  lists  is  very  similar  to  the  framework  for  strictness  analysis  for 
higher-order  functional  languages  without  non-flat  domains  (lists).  Both  analyses  use  a 
two-element  domain  as  their  basic  abstract  domains,  respectively.  Thus,  the  order  of  time 
complexity  of  escape  analysis  is  the  same  as  that  of  strictness  analysis  for  higher-order 
languages  with  non-flat  domains,  which  is  exponential  in  the  number  of  arguments  to  the 
function  being  analyzed  in  case  of  non-higher-order  functions.  In  case  of  a  higher-order 
function,  the  complexity  is  much  worse  than  exponential  in  the  number  of  arguments  to 
the  function  being  analyzed,  and  depends  on  the  types  of  its  arguments.  However,  the 
improved  escape  analysis  uses  a  (p  -f-  2)-element  domain  as  its  basic  abstract  domain.  So, 
the  order  of  time  complexity  of  improved  escape  analysis  is  higher  than,  but  comparable  to, 
that  of  strictness  analysis  for  higher-order  languages  with  non-flat  domains.  The  abstract 
interpretation  framework  for  strictness  analysis  for  higher-order  functional  languages  with 
flat  domains  uses  a  ^-element  domain  as  its  abstract  domain  where  k  is  fixed  but  greater 
than  2.  Thus,  when  compared  with  the  complexity  of  strictness  analysis  for  higher-order 
functional  languages  with  non-flat  domains,  the  complexity  of  escape  analysis  is  less,  and 
the  complexity  of  improved  escape  analysis  is  similar  to  that. 

Fortunately,  as  is  true  for  many  analyses,  worst-case  situations  rarely  occur  in  practice 
and  the  number  of  iterations  required  is  typically  small.  Furthermore,  the  average  number 
of  arguments  to  functions  does  not  grow  with  the  size  of  a  program,  and  thus  if  an  arbitrary 
bound  is  placed  on  the  number  of  arguments,  then  the  analysis  based  on  the  abstract  escape 
semantics  can  be  shown  to  be  linear  in  program  size. 
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Chapter  3 


Refinements  of  Escape  Analysis 


The  escape  analysis  described  in  the  previous  chapter  is  concerned  with  the  escapement 
properties  of  arguments  and  local  objects  of  a  function.  These  objects  are  treated  as  a  whole 
with  respect  to  the  activation  of  the  function  call.  That  is,  even  when  only  some  part  of 
such  an  object  escapes,  the  escape  analysis  indicates  only  that  the  object  escapes.  Thus,  for 
structured  objects  such  as  lists  and  trees,  the  escape  information  that  is  obtainable  through 
the  escape  analysis  is  rather  coarse  because  it  does  not  specify  the  escaping  substructure 
even  when  only  some  part  of  a  structured  object  escapes.  Such  refined  escape  information, 
if  inferred  at  compile-time,  can  be  useful  for  more  efficient  management  of  storage  for 
structured  objects. 

In  this  chapter,  we  present  a  method  for  computing  more  refined  escape  information 
for  a  higher-order,  monomorphic,  strict  functional  language.  This  method  is  based  on  a 
compile-time  semantic  analysis  called  refined  escape  analysis  which  is  an  extension  of  the 
escape  analysis  and  indicates  at  compile-time  how  much  of  an  object  such  as  argument  or 
local  object  of  a  function  outlives  the  activation  of  the  function  call.  First,  we  introduce 
a  non-standard  denotational  semantics  called  refined  escape  semantics  that  describes  the 
actual  refined  escape  behavior,  but  is  incomputable  at  compile-time.  A  safe  and  computable 
abstraction  of  the  exact  refined  escape  semantics  is  then  presented.  Based  on  the  abstract 
refined  escape  semantics ,  we  describe  the  escape  testing  algorithms  which  determine  refined 
escape  information.  Another  safe  and  computable  abstraction  of  the  exact  escape  semantics, 
called  improved  abstract  refined  escape  semantics,  that  improves  the  precision  of  refined 
escape  information  is  also  presented  using  the  position  information  of  objects  in  a  list 
structure.  Finally,  the  relationship  between  escape  analysis  and  refined  escape  analysis 
with  respect  to  their  information  content  is  discussed. 
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3.1  Refined  Escapement  of  Objects 


The  escape  model  described  in  the  previous  chapter  is  concerned  with  the  escapement  of 
arguments  each  of  which  is  treated  as  a  whole  object.  Thus,  for  structured  data  objects 
such  as  lists,  the  escape  information  that  can  be  obtainable  through  the  escape  analysis  is 
rather  weak.  Consider,  for  example,  the  append  function  defined  as  follows: 

letrec  append  x  y  =  if  (null  x)  then  y 

else  cons  (car  x)  (append  (cdr  x)  y) ; 
in  ...  append  [1,2,3]  [4,5,6]  ... 

We  assume  that  append  is  typed  as  ini  list  — >  ini  list  — >  int  list.  From  the  escape  analysis 
described  in  the  previous  chapter,  we  can  only  conclude  that  both  the  first  and  the  second 
parameters  of  append  could  escape  as  follows:  The  definition  of  the  escape  semantic  value 
append  of  append  (shown  uncurried  for  convenience)  is: 

append  x  y  =  j/U(iU  append  x  y  ) 

The  meaning  of  append  is  found  by  hxpoint  iteration  as  follows:. 

append  =  (0,  Xx.(x^,  X y.x  U  y)). 

Let  env0  be  defined  as  env0  =  [append  i— >  append]  Then, 

G .escape? (append,  1,  ehv0)  =  (Oe[append  x  y] env'0)^ 

=  (<((), «•/••/•) (({ i,f •/•?•))), n  ...  l 

where  env'0  =  env0[x  i->  (1,  err),  y  hh-  (0,  err)].  And, 

G_escape?(append,  2,  ehv0)  =  (Oe[append  x  y Jenv'0)^ 

=  ((0,  err)  U  ((1,  err)))^  =  1 

where  env'0  =  ehv0[x  t— >  (0,err),y  (l,err)].  Thus,  we  conclude  that  append  returns  its 

first  and  second  arguments  x  and  y.  In  fact,  however,  only  some  portion  of  the  second 
parameter  y  of  the  function  append  actually  escapes,  but  some  portion  does  not  escape. 

In  this  chapter  we  will  describe  a  method  for  inferring  more  precise  escape  information 
for  structured  objects  such  as  lists.  We  first  define  the  notion  of  partial  escapement  which 
specifies  more  a  refined  notion  of  escapement  of  objects  as  shown  in  Figure  3.1. 

Definition  3.1  (Global/Local  Refined  Escapement)  Given  a  function  /  with  n  for¬ 
mal  parameters  and  m  locally  defined  objects,  the  ith  formal  parameter  or  local  object  is 
said  to 
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Figure  3.1:  Refined  Escapement  of  Objects 

•  partially-escape  the  function  call  to  /  globally  if,  in  some  possible  application  of  /  to 
n  arguments,  some  part  of  the  corresponding  actual  argument  or  local  object  outlives 
the  activation  of  the  function  call,  but  the  rest  of  the  corresponding  actual  argument 
or  local  object  does  not  outlive  the  activation  of  the  function  call. 

•  partially-escape  the  function  call  to  /  locally  in  (f  e  i  . .  ,en)  if,  in  the  particular  func¬ 
tion  application  of  (  /  ex  . .  ,en),  some  part  of  the  corresponding  actual  argument  or 
local  object  outlives  the  activation  of  the  function  call,  but  the  rest  of  the  correspond¬ 
ing  actual  argument  or  local  object  does  not  outlive  the  activation  of  the  function 
call. 

When  all  of  an  object  outlives  a  function  call  globally  (or  locally),  we  say  that  the  object 
totally-escapes  the  function  call  globally  (or  locally). 

We  will  develop  a  method  for  higher-order,  monomorphic,  strict  functional  languages  to 
answer  the  following  questions  at  compile-time: 

•  Given  a  function,  which  parameter  or  local  object  defined  inside  the  function  escapes 
the  function  call  globally  and  to  what  extent  (i.e.  how  much  of  the  object  escapes)? 

•  Given  a  function  in  a  particular  application  context,  which  parameter  or  local  object 
defined  inside  the  function  escapes  that  particular  function  call  and  to  what  extent? 
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Figure  3.2:  Spines  of  a  List 

3.2  Refined  Escape  Analysis 

3.2.1  Spines  of  a  List 

In  a  refined  escape  model,  we  divide  objects  into  their  subcomponents  and  we  are  concerned 
with  how  much  of  an  object,  such  as  a  parameter  or  local  object,  escapes  the  function. 
We  describe  a  way  of  partitioning  list  objects  into  subcomponents  based  on  the  notion  of 
spines  of  a  list  as  is  shown  in  Figure  3.2. 

Definition  3.2  (Spines  of  a  List)  Given  a  list  L  and  some  i  >  1,  the  top  ith  spine  of  L 
is  defined  as  the  set  of  cons  cells  accessible  by  a  sequence  of  operations  consisting  of  car 
and  cdr  where  the  number  of  occurrences  of  car  is  ( i  —  1).  Similarly,  given  a  list  L  with  d 
spines  and  some  j  >  1,  the  bottom  jth  spine  of  L  is  defined  as  the  top  (d  —  j  +  1)  spine  of  L. 

We  have  chosen  to  analyze  the  escape  properties  of  lists  in  terms  of  their  spines  for  two 
reasons: 

•  It  is  an  approximation  to  the  run-time  behavior  that  allows  a  compile-time  analysis. 

•  It  reflects  the  programming  style  commonly  used  for  strongly  typed  languages,  such  as 
ML,  in  which  lists  are  homogeneous  (all  elements  have  the  same  type)  and  functions 
(such  as  append,  map,  etc.)  often  operate  over  complete  spines  of  lists. 

The  first  point  reflects  our  inability  to  determine  precisely,  without  actually  running  the 
program,  which  individual  cells  of  a  list  might  escape.  To  form  a  terminating  compile-time 


51 


escape  analysis,  one  must  choose  an  approximation  of  program  behavior.  The  second  point 
reflects  our  belief  that  the  spines  are  a  good  choice  of  approximation,  since  the  cells  of  each 
spine  of  a  list  tend  to  be  treated  identically.  Many  functions,  such  as  append,  reduce,  map, 
length,  etc.,  operate  on  all  cells  of  a  spine.  Many  other  functions  have  the  form: 

f  1  =  if  predicate (car  1)  then  . . .  else  f  (cdr  1) 


or 


g  1  x  =  if  x=n  then  . . .  else  g  (cdr  1)  (arith-op  x) 

In  general,  it  is  impossible  to  determine  at  compile  time  when  the  recursion  will  bottom 
out.  One  simply  has  to  assume  that  all  cells  in  the  spine  of  the  list  L  will  be  visited. 

3.2.2  Exact  Refined  Escape  Semantics 

We  introduce  an  exact,  but  incomputable,  non-standard  denotational  semantics  called  re¬ 
fined  escape  semantics ,  which  exactly  describes  the  operational  notion  of  refined  escapement 
for  functions  in  a  program.  Our  refined  escape  semantics  is  also  defined  in  terms  of  a  single 
interesting  object,  because  we  consider  that  each  parameter  or  local  object  will  be  analyzed 
separately  to  determine  its  refined  escape  behavior. 

Representing  Refined  Escape  Information 

The  meaning  we  will  attach  to  the  syntax  is  the  refined  information  about  escaping  objects. 
For  each  expression,  we  want  its  corresponding  value  in  the  extended  escape  semantic 
domain  to  be  able  to  tell  us  how  much  of  an  interesting  object  is  contained  in  the  value 
of  the  expression  (“partial-escape”).  Under  the  non-standard  refined  escape  semantics,  we 
represent  the  meaning  of  an  expression  as  a  pair,  called  a  refined  escape  pair , 

1.  whose  first  element  denotes  the  containment  and  the  extent  of  an  interesting  object 
in  the  value  of  the  expression,  and 

2.  whose  second  element  denotes  the  functional  behavior  of  the  expression  defined  over 
the  escape  pairs  when  the  expression  itself  is  applied  to  another  expression. 

For  a  non-fist  type  expression,  the  corresponding  value  in  the  non-standard  refined  escape 
semantic  domain  Dp  has  two  components:  The  first  component  is  an  element  of  a  domain 
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<M> 


(1,1) 

(1,0) 

(0,0) 


Figure  3.3:  The  Basic  Refined  Escape  Domain 

called  a  basic  refined  escape  domain ,  Bp,  for  some  fixed  d  is  a  (d  +  2)-element  domain  of 
pairs  as  shown  in  Figure  3.3.  The  ordering  on  pairs  in  Bp  is  defined  as  follows: 

(o,o)c(i,o)c(i,i)c...c(M-i)c(M) 

The  interpretation  of  elements  of  Bp  is  defined  as  follows: 

•  (1,  j)  :  Only  the  bottom  j  spines  of  an  interesting  object  is  contained  in  the  value  of 
the  expression,  and  the  rest  of  an  interesting  object  is  not  contained.  (If  an  interesting 
object  is  not  a  list  then  j  will  always  be  0,  which  means  that  an  indivisible  interesting 
object  is  contained  in  the  value  of  the  expression.) 

•  (0,0)  :  No  part  of  any  interesting  object  is  contained  in  the  value  of  the  expression 
whose  evaluation  is  ever  terminating. 

The  second  component  is  a  function  over  Dp,  whose  meaning  is  the  functional  behavior  of 
the  expression  when  the  expression  itself  is  applied  to  another  expression.  For  expressions 
which  have  no  higher-order  behavior,  err,  which  is  a  function  that  can  never  be  applied, 
is  used.  For  a  list  type  expression,  the  value  in  the  escape  semantic  domain  is  a  list  that 
consist  of  the  values  of  its  components  in  the  refined  escape  semantic  domains. 

Refined  Escape  Semantic  Domains 

The  refined  escape  semantic  domain  Dp  and  the  domain  of  refined  escape  environments  Ep 
are  defined  as  follows: 
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Dp  =  ^ Dp  /*  Refined  escape  semantic  domain  */ 

Ep  =  Id  —  Zip  /*  Domain  of  refined  escape  environments  */ 

The  refined  escape  domain  Dp  is  a  sum  domain  of  each  subdomain  of  each  type.  The  refined 
escape  subdomain  DTp  for  expressions  of  type  r  is  defined  as  follows: 


jjint 

V 

=  Bp  X  {err} 

subdomain  for  integers 

T^bool 

V 

=  Bp  X  {err} 

subdomain  for  booleans 

DTl  ~^T2 

p 

=  Bp  x  (  Dp  DTp2) 

subdomain  for  functions  of  type  T\  —  T2 

JJT  list 

V 

=  (Bpx{err})  +  {D;xD;list) 

subdomain  for  lists  of  type  r  list 

Refined  Escape  Semantic  Functions 

The  non-standard  refined  escape  semantic  functions  are  defined  as  follows: 

Pc  :  Con  —  Dp  /*  Refined  escape  function  for  constants  */ 

Pe  :  Exp  — >  Ep  —  Dp  /*  Refined  escape  function  for  expressions  */ 

Ppr  :  Program  Dp  /*  Refined  escape  function  for  programs  */ 

The  semantic  equations  for  the  refined  escape  semantic  functions  Pc  that  gives  non-standard 
refined  escape  meaning  to  constants,  Pe  that  gives  non-standard  refined  escape  meaning 
to  expressions,  and  Ppr  that  gives  non-standard  refined  escape  meaning  to  programs,  are 
expressed  in  Figure  3.4.  Note  that  Oracle  is  also  used  to  resolve  the  exact  escape  behavior 
of  the  conditional  expression  if.  envp  is  any  exact  refined  escape  environment  in  Ev,  and 
nullenVp  is  a  refined  escape  environment  that  maps  every  identifier  to  the  least  element  of 
its  refined  escape  semantic  domain. 

3.2.3  Abstract  Refined  Escape  Semantics 

We  present  a  safe  and  computable  abstraction  of  the  exact  refined  escape  semantics  defined 
in  the  last  section  that  allows  an  approximation  of  the  exact  escape  behavior  of  functions 
to  be  found  at  compile- time. 

We  safely  approximate  the  exact  refined  escape  semantics  by  abstracting  the  refined 
escape  semantic  subdomains  for  list  type  expressions,  and  by  approximating  the  refined 
escape  semantic  functions.  For  each  expression,  its  corresponding  value  in  the  abstract  ex¬ 
tended  escape  semantic  domain  tells  us  how  much  of  an  interesting  object  may  be  contained 
in  the  value  of  the  expression  (“maybe  partial-escape”).  The  abstract  basic  refined  escape 
domain,  Bp  for  some  fixed  d  is  a  (d-\~  2)-element  domain  that  is  similar  to  the  basic  refined 
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Pc[c]  =  ((0,  0),  err),  c  ={...,  — 1,  0, 1, true,  falsejiilr  hst} 

Pc[cons]  =  ((0,  0),  Xx.(x^,  Xy.  pair(x,  y))) 

Pc[car]  =  ((0,  0),  Ax.  first  (a:)) 

Pc[cdr]  =  ((0,  0),  Ax.  second(x)) 

Pc  [null]  =  ((0,0),  Ax. ((0,0),  err)) 

Pelcjenvp  =  Pc[c\ 

Pe{xjenvp  =  envPlxJ 

Pe[e i  +  e2 Jenvp  =  ((0,0),  err)  /*  same  for  ej  —  e2  and  ej  =  e2  */ 

Pe[  if  Si  then  e2  else  e^\envp  =  if  Oracle(ei)  then  (Pe\.e2\envP)(i) 

else  ( /',  [eslerr/;,,) 

Pe[eie2]enrp  =  (Pe[ei]enrp)(2)  (Pele2}envp) 

Pe[lambda(x).e]erirp  =  (V,  Xy.Pele}envp[x  y]) 

where 

V  —  (0,  0)  U  (  y  (eni7p[z])(1))  U  (  [_\  (  [J  p(1))) 

z£]?non  —  list  z^jplist  p  in  (envp  JV]) 

p  in  (envpl_zj)  denotes  that  p  is  an  refined  escape  pair  in  enrp[z], 
pnon-hst  _  ge^  Qf  non-hst  type  free  identifiers  in  (lambda(x).e),  and 
jphst  _  ge^  0f  ipst  type  free  identifiers  in  (lambda(x).e). 

Pe[letrec  x\  —  eg[;| . . . ;  xn  =  en\  in  e\envp  =  Pe\e\env'p 

where  env'p  =  envp[x1  i—  Pe[ei]enr(,, . .  .  ,x„  ^  Pelen}env'p] 

PprlprJ  =  Pelprjnullenvp 

Figure  3.4:  Refined  Escape  Semantic  Functions 
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<M> 


(1,1) 

(1,0) 

(0,0) 


Figure  3.5:  The  Abstract  Basic  Refined  Escape  Domain 
escape  domain  Bp  as  is  shown  in  Figure  3.5.  The  ordering  is  also  defined  as  follows: 


(0,0)  C  (1,0)  C  (1, 1)  C  ...  C  {l,d-  1)  C  (l,d) 

But,  the  interpretation  of  elements  of  Bp  is  dehned  differently  from  the  interpretation  of 
Bp  as  follows: 

•  (1,*)  :  Only  the  bottom  <  i  spines  of  an  interesting  object  may  be  contained  in  the 
value  of  the  expression.  (If  an  interesting  object  is  not  a  list  then  i  will  always  be  0, 
which  means  that  an  indivisible  interesting  object  may  be  contained  in  the  value  of 
the  expression.) 

•  (0,  0)  :  No  part  of  any  interesting  object  is  contained  in  the  value  of  the  expression. 

The  abstraction  of  the  refined  escape  semantic  subdomains  for  list  type  expressions  is  done 
by  representing  lists  as  finite  objects,  i.e.  by  combining  the  escape  pairs  of  all  its  elements 
into  a  single  escape  pair.  The  abstract  refined  escape  semantic  domain  Dp  and  the  domain 
Ep  of  abstract  refined  escape  environments  are  dehned  as  follows: 

Dp  =  /*  Abstract  refined  escape  semantic  domain  */ 

Ep  =  Id  — »■  Dp  /*  Domain  of  abstract  refined  escape  environments  */ 

The  abstract  refined  escape  subdomain  Dp  for  expressions  of  type  r  is  dehned  as  follows: 
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D =  Bp  X  {err}  abstract  subdomain  for  integers 

b\ \°°l  =  bp  X  {err}  abstract  subdomain  for  booleans 

Dp 1^T2  =  Bp  X  (Dp1  Dp2)  abstract  subdomain  for  functions  of  type  T\  — ►  T2 

Dp  llst  =  Dp  abstract  subdomain  for  lists  of  type  r  list 

The  abstract  refined  escape  semantic  functions  are  defined  as  follows: 


Pc 

:  Con 

->  Dp 

/*  Abstract  refined  escape  function  for  constants  */ 

Pe 

:  Exp 

-  Ep  - 

-  Dp 

/*  Abstract  refined  escape  function  for  expressions  */ 

p 

±  pT 

:  Prog 

ram  — 

Dp 

/*  Abstract  refined  escape  function  for  programs  *  j 

The  abstract  refined  escape  semantic  functions  are  given  in  Figure  3.6. 

The  abstract  value  of  cons  returns  a  single  refined  escape  pair  that  is  approximating 
a  list  of  refined  escape  pairs  by  taking  the  least  upper  bound  of  its  two  arguments.  The 
cars  denotes  a  car  that  is  applied  to  an  argument  of  a  list  type  with  s  spines.  For  each 
car  in  a  program,  s  can  be  determined  statically  by  type  checking.  It  may  be  arbitrarily 
large,  but  is  fixed  at  compile-time.  The  abstract  value  of  car  is  defined  as  follows:  cars 
takes  a  list  with  s  spines  as  an  argument,  and  returns  a  list  with  (s  —  1)  spines  when  s  >  1 
or  a  non- list  object  when  s  =  1.  In  any  case,  the  result  cannot  contain  an  interesting 
object  with  s  spines.  The  abstract  value  of  cdr  just  returns  its  argument  list.  envp  is 
any  abstract  refined  escape  environment  in  Ep,  and  nullenvp  is  an  abstract  refined  escape 
environment  that  maps  every  identifier  to  the  least  element  of  its  abstract  refined  escape 
semantic  domain. 

The  safety  of  interpretation  under  the  abstract  refined  escape  semantics  with  respect 
to  the  exact  refined  escape  semantics  can  be  proved  as  follows.  Let  u  and  v  be  values  of 
an  expression  e  of  type  r  in  the  abstract  refined  escape  domain  Dp  and  the  exact  refined 
escape  domain  Dp,  respectively.  Let  n  be  the  number  of  arguments  that  the  type  r  can 
take  before  returning  a  value  of  primitive  type.  We  say  that  the  abstract  refined  escape 
semantic  value  u  is  a  safe  approximation  ( with  respect  to  refined  escape  information)  of  the 
exact  refined  escape  semantic  value  v  iff 

(  U  P(i))  E  (NAPjt(u,  Si,...,  «*))(!) 

p  in  NAPfc(:it, 

for  all  k  <  n  where  st  is  a  safe  approximation  of  lt  for  all  i  <  k. 

Theorem  3.1  (Safety)  For  any  expression  e,  and  environments  envp  and  envp  such  that 
for  all  y,  effup[j/]  is  safe  for  envp\;yj,  Pe\e\ehvp  is  safe  (with  respect  to  refined  escape 
information)  for  Pe\e\envv. 
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Pc[c\  =  ((0,  0),  err),  c  =  {..., -1, 0, 1, true,  false} 

Pc[nilT  =  _Lr  (The  bottom  element  in  I)’,) 

Pjcons]  =  ((0,  0),  Xx.(x^,  Xy.x  U  y)) 

Pc[cars]  =  ((0,  0),  Aa\subs(a)) 

where 

subs (2)  =  if  i)(2)  -  s)  then  (<^(1)(1),  max(z(1)(2)  -  1,0)),  z^)  else  2 
Pc[cdr]  =  ((0, 0),  Xx.x) 

Pc  [null]  =  ((0,0),  Aa.  ((0,0),  err)) 

Pelcjenvp  =  Pc[c] 

Pe{xjenvp  =  envp{xj 

Pe[e  1  +  e2 Jenvp  =  ((0,0),  err)  /*  same  for  ej  —  e2  and  =  e-i  */ 

Pel  if  «i  then  e2  else  e3]ehrp  =  (Pe[e2]efirp)(2)  U  (. Pe{e3}envp ) 

Pe[eie2]ehrp  =  (Pe[ei]en%|(2)  (Pe[e2]ehrp) 

P  [lambda(a).'  |(  jt'fy  =  (l  .  [<  [' frr;,,[a  --  !j\) 

where 

F  =  (0,  0)(  [J  (erirPH)fl))  and 
F  =  Set  of  free  identifiers  in  (lambda(a).e). 

Pe[letrec  =  e1; . . . ;  xn  =  en\  in  e\envp  =  Pe[e]e»Vp 

where  env'p  =  erirpfa!  h->  Pe[ei]ehrp, . . . ,  xn  Pe[ere]en^] 

Ppr[pr]  =  PelprJnuUenVp 

Figure  3.6:  Abstract  Refined  Escape  Semantic  Functions 
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Proof  :  We  can  prove  by  structural  induction  on  expression  e. 

I.  Base  Case: 

1.  e  -  c:  Pe\c\envp  =  Pc[c]  and  Pe\c\envp  =  Pc[c],  For  c  £  ,  -1,  0,  1, 

true,  false,  nil,  null  }  ,  Pc[c]  =  Pc[c]  =  ((0,0),  err).  It  holds  for  c  =  cons,  because, 
if  x\  and  X2  are  safe  for  yi  and  3/2  respectively,  x\  U  X2  is  also  safe  for  a  list  consisting  of  yi 
and  j/2-  For  c  =  cars,  it  holds  because  if  x  is  safe  for  y  then  subs(a:)  is  safe  for  first(y).  It 
holds  for  c  =  cdr,  because  Pc[c]  =  Pc[c]  =  ((0,  0),  Xx.x). 

2.  e  =  x:  Pe\x\envp  =  enrp[s]  and  Pe\;x\envp  =  envp\ a-].  Since,  for  all  y,  envp\y\  is 
safe  for  envp\y\,  it  clearly  holds. 

II.  Structural  Induction  Step:  Assume  that  Pe\e\ehvp  is  safe  for  Pe\e\envp  for  expressions 
such  as  eo,  e2,  e%  and  en  (structural  induction  hypothesis).  Then,  we  show  that  Pe\e\ehvp 
is  safe  for  Pe\e\envp  for  e  =  e\  +  e2,  if  e\  then  e2  else  e 3,  e^,  lambda(a:).ei,  and 
letrec  xi  =  ej.j . . . ;  xn  =  e„;  in  eo-  This  step  can  be  proved  in  an  exactly  same  way  to  the 
safety  proof  of  the  abstract  escape  semantics  with  respect  to  the  exact  escape  semantics.  □ 

Theorem  3.2  (Termination)  For  any  (finite)  program  pr  £  Program,  Ppr[pr]  is  com¬ 
putable. 

Proof  :  Every  functional  in  the  refined  escape  domain  that  is  defined  through  the  abstract 
refined  escape  semantic  functions  is  composed  of  the  operators  such  as  the  least  upper  bound 
operator  U  and  subs,  which  are  monotonic.  Furthermore,  each  subdomain  D)  is  finite.  □ 

3.2.4  Refined  Escapement  Testing 

The  abstract  refined  escape  semantics  can  be  used  as  a  basis  for  inferring  refined  escape 
information  because  interpretation  under  this  semantics  is  effective.  We  describe  the  refined 
escape  testing  algorithms  in  which  the  abstract  functions  are  used  to  detect  the  refined 
escape  properties  of  the  corresponding  functions  in  a  program. 

Global  Refined  Escape  Test 

Given  a  function  /  x\  X2  ■  ■  ■  xn  =  bodyj  of  arity  n,  the  position  i  of  an  interesting 
parameter,  and  an  abstract  refined  escape  semantic  environment  envp  mapping  /  to  an 
element  of  Dp,  the  global  refined  escape  test  function  G_rescape?  determines  how  much  of 
the  ith  parameter  of  /  could  possibly  escape  /  globally.  It  is  defined  as  follows: 

G_rescape?  (  /,  i,  ehvp)  -  ( Pe{f  Xi  . . .  xn\  ( nvP[xt  i->  t/*])^ 
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where 


yi  -  (( 1 .  ,Xj).  It  '■).  /*  The  ith  parameter  is  an  interesting  object  */ 

Si  is  the  number  of  spines  of  the  ith  parameter  of  /  (if  it  is  a  list  type,  otherwise  Si  is  0), 
for  all  j  <  n  and  j  ^  i. 

y:i  —  ((0,  0),  WTi)i  /*  Other  parameters  are  not  interesting  objects  */ 

and  Ti  is  the  type  of  the  ith  parameter  of  /.  Note  that  the  whole  ith  argument  with 
spines  is  interesting,  and  any  other  argument  is  not  interesting.  Then,  from  the  result  of 
the  global  refined  escape  test  function,  we  can  conclude  as  follows: 

•  ff  G_rescape?(/,  i,  ehvp)  =  (0,0)  then  we  conclude  that  none  of  the  ith  argument 
escapes  /  in  any  possible  application  of  /  to  n  arguments. 

•  ff  G_rescape?(/,  i,  envp)  =  (f,  k)  then  we  conclude  that,  if  st  >  1  then,  the  top  (s;  —  k ) 
spines  of  the  ith  argument  do  not  escape  /  in  any  possible  application  of  /  to  n 
arguments,  but  the  bottom  k  spines  of  the  ith  argument  could  escape  /  in  some 
application  of  /  to  n  arguments.  If  st  =  0  then  the  ith  argument,  which  is  not  a  list 
type,  could  escape  in  some  application  of  /  to  n  arguments. 

Local  Refined  Escape  Test 

Given  a  function  /  x\  ■  ■  ■  xn  =  bodyj  of  arity  n  in  an  application  /  ey  ...  e„,  the 
position  i  of  an  interesting  parameter,  and  an  abstract  escape  semantic  environment  envp 
mapping  /  and  the  free  identifiers  within  e1  through  en  to  elements  of  Dp,  the  local  escape 
test  function  L_rescape?  determines  how  much  of  the  ith  parameter  of  /  could  escape  /  in 
the  evaluation  of  /  e1  ...  en.  It  is  dehned  as  follows: 

L_rescape?(  /,  i,  e1} . . . ,  en,  envp )  =  (Pe[/  x1  . . .  xnj  envp[xi  ^  .(/«])(  ,) 

where 

yi  —  ((1,  s^,  (Pe[e!']  e'kvP)(2)),  /*  The  ith  parameter  is  an  interesting  object  */ 

Si  is  the  number  of  spines  of  the  ith  parameter  of  /  (if  it  is  a  list  type,  otherwise  s,t  is  0), 
and  for  all  j  <  n  and  j  /  i. 

yj  =  ((0,0),  (Pe[ej]  envp)(2))-  /*  Other  parameters  are  not  interesting  objects  */ 
Then,  from  the  result  of  the  local  refined  escape  test  function,  we  can  conclude  that: 
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•  If  L_rescape? (/,  i,  ei, . . . ,  en,  ehvv)  =  (0,  0)  then  none  of  the  ith  argument  escapes  /  in 
the  particular  application  of  /  to  %  through  en. 

•  If  L_rescape?{  /,  i,  ei, . . .  ,en,envp)  =  (1,  A:)  then  we  conclude  that,  if  >  1  then,  the 
top  ( Si  —  k)  spines  of  the  ith  argument  do  not  escape  /  in  the  particular  application 
of  /  to  e\  through  e„,  but  the  bottom  k  spines  of  the  ith  argument  could  escape.  If 
Si  =  0  then  the  ith  argument,  which  is  not  a  list  type,  could  escape  in  the  particular 
application  of  /  to  ej  through  en. 

Examples 

As  an  example,  consider  the  following  partition  sort  program: 

letrec  ps  x  =  if  (null  x)  then  nil 

else  letrec  y  =  split  (car  x)  (cdr  x)  nil  nil; 
in  append  (ps  (car  y)) 

(cons  (car  x)  (ps  (car  (cdr  y)))); 

split  p  x  1  h  =  if  (null  x)  then  (cons  1  (cons  h  nil)) 
elseif  (car  x)<p  then 

split  p  (cdr  x)  (cons  (car  x)  1)  h 
else  split  p  (cdr  x)  1  (cons  (car  x)  h) ; 

append  x  y  =  if  (null  x)  then  y 

else  cons  (car  x)  (append  (cdr  x)  y) ; 

in  ps  [5,2,7, 1 ,3,4] 

We  assume  that  the  type  of  each  function  is  given  by 
ps  :  int  list  —  int  list 

split  :  int  — >  int  list  —  int  list  — *  int  list  — ►  int  list  list 
append  :  int  list  — >  int  list  — ►  int  list 

From  type  checking,  each  car  in  the  program  can  be  annotated  as  follows: 

ps  x  =  if  (null  x)  then  nil 

else  letrec  y  =  split  (CAE1  x)  (cdr  x)  nil  nil; 
in  append  (ps  (CAR2  y)) 

(cons  (CAR1  x)  (ps  (CAR2  (cdr  y)))); 


61 


split  p  x  1  h  =  if  (null  x)  then  (cons  1  (cons  h  nil)) 
elseif  (CAR1  x)<p  then 

split  p  (cdr  x)  (cons  (CAR1  x)  1)  h 
else  split  p  (cdr  x)  1  (cons  (CAR1  x)  h) ; 

append  x  y  =  if  (null  x)  then  y 

else  cons  (CAR1  x)  (append  (cdr  x)  y) ; 

where  CARi  denotes  a  car  that  takes  as  its  argument  a  list  with  i  spines.  The  refined 
escape  semantic  values  append,  split,  and  ps  of  append,  split,  and  ps  (shown  uncurried 
for  convenience)  are  expressed  as  follows: 

append  x  y  =  y  U  (sub1  (a;)  U  append  x  y) 

split  p  x  l  h  =  l  U  h  U  ( split  p  x  (sub1(r)  U  l )  h)  U  ( split  p  x  (sub1(r)  U  h)) 
ps  x  =  append  {ps  sub 2(split  sub1(r)  x  ((0,0 )err)  ((0,0 )err)  j) 

(sub1(a;)  U  (ps  sub 2(split  sub1(r)  x  ((0,  0)err)  ((0,  0)err))) 

The  meaning  of  each  function  in  the  refined  escape  semantic  domain  is  found  by  fixpoint 
iteration.  The  fixpoint  iteration  for  append: 

append )°)  x  y  =  ±int  ust 

append1'1')  x  y  =  y  U  (sub1  (a;)  U  append x  y) 

=  y  U  sub1  (a;) 

append1'2')  x  y  =  y  U  (sub1  (a;)  U  append W  x  y) 

=  y  U  (sub1(a:)  U  ( y  U  sub1(a:))) 

=  y  U  sub1  (a;) 

Since  append)2)  =  append)3),  we  have  that 

append  =  ((0,  0),  Aa;.^^,  A y.y  U  sub1(a:))). 

The  fixpoint  iteration  for  split: 
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split (0)  pxlh  =  ±(mt  Ust)  [ist 

split (  l  p  x  l  h  lUhU  -L^nt  nst}  nst  LI  -L^int  nst)  list 
=  l  U  h 

split^l  pxlh  =  l  U  h  U  (splits  p  x  (sub1(x)  U  /)  h)  U  ( split W  p  x  (sub1^)  U  //)) 
=  lUhU  ((sub1(x)  U  l )  U  h)  U  ((sub1(a;)  U  h )) 

=  !  U  h  U  sub1(x) 

split(3l  pxlh  =  l  U  h  U  (splits  p  x  (sub1(x)  U  /)  h)  U  (split^  p  x  (sub1(a;)  U  h)) 
=  I  U  h  U  ((sub^a)  U  /)  U  h)  U  (/  U  (sub1(a;)  U  h)  U  sub1(x)) 

=  l  U  h  U  sub^a) 

Since  split (2)  =  split^3\  we  have  that 

split  =  ((0,  0),  A p.{p(\),  A x.(p^}  U  x^),  Al.(p(i)  U  a^)  U  Z^,  Xh.l  U  h  U  sub1(x))))). 

The  hxpoint  iteration  for  ps: 

pS ^  ^  X  —  -hint  list 

p.s^1)  x  =  append(ps( °)  sub2(sub1(x)))  (sub^a)  U  ( ps(° )  sub2  (sub1  (a))) 

=  append  ±int  ust  (sub1(sub1(a:))  U  ±mt  ust) 

=  sub1(x) 

ps^2l  x  =  append{ps^  sub2(sub1(a;)))  (sub1(a;)  U  (psW  sub2(sub1(a:))) 

=  append  sub1(sub2(sub1(a:)))  (sub1(a:)  U  sub1(sub2(sub1(a;))) 

=  sub1(x) 

Since  ps^  =  ps^2\  we  have  that 
ps  —  ((0,  0),  Aa.sub^a)). 

Let  envp  be  defined  as  envp  =  [append  i-r  append,  split  i-r  split, ps  i— >  ps].  Then, 

G_rescape?(append,  1,  ehvp)  =  (Pe[append  x  y Jeru/p)^ 

=  (((0,  0),  err)  U  sub1(((l,  1),  err)))(1) 

=  (i,o) 

where  env'p  =  ehvp[x  i-+  ((1, 1),  err),  y  ((0,  0),  err)]. 

G_rescape?(append,  2,  ehvp)  =  (Pe[append  x  yJenPp)^) 

=  (((0,  0),  err)  U  sub1(((l,  1),  err)))(1} 

=  (1,1) 

where  env'p  =  ehvp[x  i-+  ((0,  0),  err),  y  ht  ((1,  l),err)].  Thus,  we  can  conclude  that  append 
returns  all  of  its  second  argument  y,  and  all  but  the  top  spine  of  the  first  argument  x. 
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G_rescape?( split,  1,  ehvp)  =  (Pe[split  p  x  1  hjf  ij 

=  (((0,  0),  err)  U  ((0,  0),  err)  U  sub1(((0,  0),  err)))(1) 

=  (o,o) 

where  env' p  =  envp[ p  i— >  ((1,  0),  err),  x,  1,  h  i— >  ((0,  0),  err)]. 

G_rescape?(  split,  2,  ehvp)  =  (Pe[split  p  x  1  h] env'p)^ 

=  (((0,  0),  err)  U  ((0,  0),  err)  U  sub1(((l,  1),  err)))(1) 

=  (i,o) 

where  env'p  =  envp[x  ((1, 1),  err),  p,  1,  h  i — ^  ((0,  0),  err)]. 

G_rescape?(  split,  3,  efivp)  =  (Pe[split  p  x  1  hjercw'p)^ 

=  (((1, 1),  err)  U  ((0,  0),  err)  U  sub1(((0,  0),  err)))(1) 

=  (1,1) 

where  env' p  =  envp  [i  h-  ((1,  l),err),p,x,hi->  ((0,  0),  err)]. 

G_rescape?(split,  4,  ehvp)  =  (Pe[split  p  x  1  hjenr'p)^^ 

=  (((0,  0),  err)  U  ((1, 1),  err)  U  sub1(((0,  0),  err)))(1) 

=  (1,1) 

where  env'p  =  envp[ h  ((1, 1),  err),p,  x,  1  ((0,  0),  err)].  Thus,  we  can  conclude  that 

split  returns  all  of  its  third  and  fourth  arguments  1  and  h,  none  of  the  first  argument  p, 
and  all  but  the  top  spine  of  the  second  argument  x. 

G_rescape?(ps,  1,  ehvp)  =  (Pe[ps  x]  ehvp[x  ((1, 1),  err)])^) 

=  (sub1(((l,  1),  err)))(1) 

=  (i,o) 

Thus,  we  conclude  that  ps  returns  all  but  the  top  spine  of  its  argument  x. 

3.3  Improving  Precision  of  Refined  Escapement 

We  describe  an  improved  abstraction  of  the  exact  refined  escape  semantics  achieved  by 
extending  the  basic  abstract  refined  escape  domain  to  include  additional  information  about 
the  positions  of  objects  in  a  list.  For  each  expression,  its  corresponding  value  in  the 
improved  abstract  refined  escape  semantic  domain  tells  us  how  much  of  an  interesting  object 
may  be  contained  at  some  position  in  the  value  of  the  expression  (“maybe  partial-escape 
and  where”).  The  basic  improved  abstract  escape  domain,  Bp,  for  some  fixed  d  and  p  is 
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(M,o) 


(lj  d,  p  -  1) 

(M,p) 

(1,0,0) 

(1,0, P-1) 

(1,0,  p) 

(0,0,0) 

Figure  3.7:  The  Improved  Abstract  Basic  Refined  Escape  Domain 
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a((d+l)(p+l)+  l)-element  domain  of  triples  as  shown  in  Figure  3.7.  The  ordering  on 
triples  in  13, p  is  dehned  as  follows: 

(0,0,0)  C  (1,0,  p)  C  (l,0,p—  1)  Q  ...  C  (1,  0,  0) . . .  (1,  d,  p)  Q  (l,d,p—  1)  C  ...  C  (l,d,  0) 
The  interpretation  of  the  elements  of  Bp  is  dehned  as  follows: 

•  (l.i.k)  :  Only  the  bottom  <  i  spines  of  an  interesting  object  may  be  contained  only 
at  positions  >  k  in  the  value  of  the  expression,  if  that  value  is  a  list.  (If  an  interesting 
object  is  not  a  list  then  i  will  always  be  0,  which  means  that  an  indivisible  interesting 
object  may  be  contained  in  the  value  of  the  expression.) 

•  (0,  0,  0)  :  No  part  of  any  interesting  object  is  contained  in  the  value  of  the  expression. 

The  improved  abstract  refined  escape  semantic  domain  Dp  and  the  domain  Ep  of  improved 
abstract  refined  escape  environments  are  dehned  as  follows: 

Dp  =  /*  Improved  abstract  refined  escape  semantic  domain  */ 

Ep  =  Id  — >  Dp  /*  Domain  of  improved  refined  escape  environments  */ 

The  improved  abstract  rehned  escape  subdomains  Dp  for  expressions  of  type  r  are  dehned 
as  follows: 

=  Bp  X  {err}  improved  abstract  subdomain  for  integers 

D*™1  =  Bp  X  {err}  improved  abstract  subdomain  for  booleans 

DJ} 1_>T2  =  Bp  X  (D^1  — *  Dp2)  improved  abstract  subdomain  for  functions 

Dp  hst  =  Dp  improved  abstract  subdomain  for  lists 

The  improved  abstract  rehned  escape  semantic  functions  are  as  follows: 

Pc  :  Con  — »  Dp  /*  Improved  semantic  function  for  constants  */ 

Pe  :  Exp  — >  Ep  Dp  /*  Improved  semantic  function  for  expressions  */ 

Ppr  :  Program  Dp  /*  Improved  semantic  function  for  programs  */ 

The  improved  abstract  rehned  escape  semantic  function  Pc  :  Con  —  Dp  that  gives  rehned 
escape  meaning  to  constants  is  given  in  Figure  3.8.  The  improved  abstract  value  of  cons 
takes  two  arguments,  and  returns  an  improved  rehned  escape  pair  of  their  least  upper  bound 
by  updating  the  position  information  of  an  interesting  object  in  the  result  list.  The  improved 
abstract  value  of  cars  returns  its  argument  according  to  the  position  of  an  interesting  object. 
cars  takes  a  list  with  s  spines  and  returns  the  element  that  was  in  the  0t/l  position  and 
has  (s  —  1)  spines.  Thus,  the  result  cannot  contain  an  interesting  object  with  s  spines  or 
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PcM 

Pc[nilr  «*] 
Pc[cons] 


Pc[cars] 


Pc[cdr] 


Pc[null] 


((0,  0,  0), err),  c{. . —  1,  0, 1, ,  true,  false} 

_Lr  (The  bottom  element  in  D £) 

((0,  0,  0),  As.(s(1),  Aj/.rpush(s,  y)))) 
where 

rpush (x,y)=  if  (r(1)(1)  =  1) 

then  ((1,  r(1)f2)  U  J/(i)(2),  0),  s(2)  U  y(2)) 
elseif  (j/(i)(i)  =  1) 

then  ((1,  J/(1)(2),min(y(1)f3)  +  l,p)),  s(2)  U  j/(2)) 
else  <<0,  0,  0),  ar(2)  U  ?/(2)) 

((0,  0,  0),  Aa\rsubs(a)) 
where 

rsubs(z)  =  if  (^(i)(i)  =  0)  or  (r(l)(3)  >  0)  then  <<0,  0,  0), z(2)) 
else  ((decsUflj2)),0),2:(2)) 

decs(y)  =  if  (j/(1)  -1  =  5)  then  (max(  j/(1)  -1,0),  j/(2)) 
else  y 

((0,  0,  0),  Aa.rrest(a)) 
where 

rrest(z)  =  <(^i)(i)»  z(i)(2),  max[a(1)(3)  -  1,  0]),  a(2)) 

((0,0,0),  As. ((0,0, 0),  err) 


Figure  3.8:  Improved  Abstract  Refined  Escape  Semantic  Functions 
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that  occurred  at  a  position  >  1  in  the  original  list.  The  improved  abstract  value  of  cdr  also 
updates  the  position  information  appropriately.  Note  that  the  improved  abstract  refined 
escape  semantic  function  Pc  for  cons,  car  and  cdr  provides  more  precise  escape  information 
than  the  abstract  refined  escape  semantic  function  Pc. 

The  improved  abstract  refined  escape  semantic  function  P,  :  Exp  —  Ep  — >  Dp  that  gives 
refined  escape  meaning  to  expressions,  and  the  improved  abstract  refined  escape  semantic 
function  Ppr  :  Program  —  Dp  that  gives  refined  escape  meaning  to  programs  are  defined 
similarly  to  the  abstract  refined  escape  semantic  function  Pe  and  Ppr  respectively. 

The  safety  of  interpretation  under  the  improved  abstract  refined  escape  semantics  with 
respect  to  the  exact  refined  escape  semantics  can  be  proved  as  follows.  Let  u  and  v  be 
values  of  an  expression  e  of  type  r  in  Dp  and  Dp,  respectively.  Let  n  be  the  number  of 
arguments  that  the  type  r  can  take  before  returning  a  value  of  primitive  type.  We  say  that 
the  improved  abstract  refined  escape  semantic  value  u  is  a  safe  approximation  ( with  respect 
to  refined  escape  information)  for  the  exact  refined  escape  semantic  value  v  iff 

(  U  P(i))  E  (NAPa,(u,s1,...,sa))(1)(1j2) 

p  in  NAPA(-u,ti,...,tA) 

and 

(  MINp  ^  NAP*(«,ti,...,t*)&p(1)(1)=iI>0sition  of  p)  >  (NAP*(u,  s1; . . . ,  ^))(1)(3) 
for  all  k  <  n  where  Si  is  a  safe  approximation  for  t{  for  all  i  <  k. 

Theorem  3.3  (Safety)  For  any  expression  e,  and  environments  envp  and  eiivp  such  that 
for  all  y,  erfnp[|/]  is  safe  for  ennp\y\,  Pe\e\ehvp  is  safe  (with  respect  to  refined  escape 
information )  for  Pe[e\envp. 

Proof  :  We  can  prove  by  structural  induction  on  expression  e. 

I.  Base  Case: 

1.  e  =  c:  Pe\c\envp  =  Pc[c]  and  Pe\c\envp  =  Pc[c]-  F°r  c  E  ,  -1,0,1,  ...,  true , 
false,  nil,  null  }  ,  Pc[c]  =  Pc[c]  =  ((0,  0,  0),  err).  It  holds  for  c  =  car,  because  if  xp 
and  X2  are  safe  for  yi  and  y-2  respectively  then  rpushfr,  y)  is  also  safe  for  a  list  of  yi  and  3/2  - 
For  c  =  cars,  it  holds  because  if  x  is  safe  for  y  then  then  rsubs(r)  is  also  safe  for  first)  y). 
It  holds  for  c  =  cdr,  because  if  x  is  safe  for  y  then  then  rrest(r)  is  also  safe  for  second)  y). 

2.  e  =  x\  Pe\x^envp  =  erfrp[x]  and  Pe\x^envp  =  erirp[a-].  Since,  for  all  y,  erfrp[|/]  is 
safe  for  envp\y\,  it  clearly  holds. 

II.  Structural  Induction  Step:  Assume  that  Pe\e\envp  is  safe  for  Pe\e\envp  for  expressions 
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RES 


SS 


IARES 


ARES  “information  content” 


Figure  3.9:  Relationship  among  Standard  and  Refined  Escape  Semantics 

such  as  eo,  ei,  e2,  e3  and  en  (structural  induction  hypothesis).  Then,  we  show  that  Pelejenvp 
is  safe  for  Pe\e\envp  for  e  =  ej  +  if  then  e2  else  e 3,  e^,  lambda(a;).ei,  and 
letrec  x\  =  ei; . . . ;  xn  =  en;  in  eo-  This  can  be  proved  in  an  exactly  the  same  as  the  proof 
of  safety  of  the  abstract  refined  escape  semantics.  □ 

Theorem  3.4  (Termination)  For  any  (finite)  program  pr  £  Program,  PflT [pr]  is  com¬ 
putable. 

Proof  :  Every  functional  in  the  improved  escape  domain  that  is  defined  through  the 
abstract  improved  refined  escape  semantic  functions  is  composed  of  the  operators  such  as 
the  least  upper  bound  operator  U,  rpush,  rsubs,  and  rrest.  rpush,  rsubs  and  rrest  are  all 
monotonic  operators.  Also,  each  subdomain  Df  is  finite.  □ 

Theorem  3.5  (Precision  Improvement)  The  abstract  refined  escape  semantics  is  equiv¬ 
alent  (with  respect  to  refined  escape  information)  to  the  improved  abstract  refined  escape 
semantics  with  p  =  0.  Thus,  the  improved  abstract  refined  escape  semantics  with  p  >  0 
provides  more  precise  escape  information  than  the  abstract  refined  escape  semantics. 

Proof  :  This  can  be  proved  in  a  similar  way  to  the  proof  of  Theorem  2.5.  □ 

The  relationships  among  the  standard  semantics  (SS),  the  exact  refined  escape  semantics 
(RES),  the  abstract  refined  escape  semantics  (ARES)  and  the  improved  abstract  refined 
escape  semantics  (IARES)  are  shown  in  Figure  3.9 


69 


Improved  Global  Refined  Escape  Test 

Given  a  function  f  x i  ij  ...  i„  =  bodyj  of  arity  n,  the  position  i  of  an  interesting 
parameter,  and  an  improved  abstract  refined  escape  semantic  environment  envp  mapping 
/  to  an  element  of  Dp ,  the  global  improved  refined  escape  test  function  GJrescape?  which 
determines  how  much  of  the  ith  parameter  of  /  could  possibly  escape  /  globally  is  defined 
as  follows: 

GJrescape? (/,  *,  efivp)  =  (Pe{f  x2  . . .  xnJ  envp[ xt  3/i])(1)p,2) 

where 

yi  =  ((1,  Si,  0),  IT1"*},  /*  The  ith  parameter  is  an  interesting  object  */ 

Si  is  the  number  of  spines  of  the  ith  parameter  of  /  (if  it  is  a  list  type,  otherwise  is  0), 
for  all  j  <  n  and  j  i. 

yj  =  ((0,0,0),  IT7"-’),  /*  Other  parameters  are  not  interesting  objects  */ 

and  T,t  is  the  type  of  the  ith  parameter  of  /.  The  result  of  the  global  improved  refined  escape 
test  function  is  interpreted  as  follows: 

•  If  GJrescape?  ( /,  i,  ehvp)  =  (0,  0)  then  we  can  conclude  that  in  any  possible  application 
of  /  to  n  arguments,  none  of  the  ith  argument  escapes  /. 

•  If  GJrescape?(/,  i,  ehvp)  =  ( 1 .  A- )  then  we  can  conclude  that  if  S{  >  1  then,  in  any 
possible  application  of  /  to  n  arguments,  the  top  (sj  —  A)  spines  of  the  ith  argument 
do  not  escape  /,  but,  in  some  application  of  /  to  n  arguments,  the  bottom  k  spines 
of  the  ith  argument  could  escape  /.  If  Si  =  0  then  in  some  application  of  /  to  n 
arguments,  the  ith  argument,  which  is  not  a  list  type,  could  escape. 

Improved  Local  Refined  Escape  Test 

Given  a  function  f  x  1X2  . .  ■  xn  =  bodyj  of  arity  n  in  a  application  context  f  e  1  ...  en, 
the  position  i  of  an  interesting  parameter,  and  an  improved  abstract  escape  semantic  envi¬ 
ronment  envp  mapping  /  and  the  free  identifiers  within  e 1  through  en  to  elements  of  Dp, 
the  local  escape  test  function  LJrescape?  which  determines  how  much  of  the  ith  parameter 
of  /  could  escape  /  in  the  evaluation  of  /  e\  . . .  en  is  defined  as  follows: 

LJrescape?  (/,  i,  e1; .  ..,en,envp)  =  ( Pe[f  x1  . . .  xnJ  envp[xt  1—  2/i]  )(i)(i,2) 

where 
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Hi  =  ((l,s,-,  0),  (Pe[e,]  envp)(2)),  /*  The  ith  parameter  is  an  interesting  object  */ 

Si  is  the  number  of  spines  of  the  ith  parameter  of  /  (if  it  is  a  list  type,  otherwise  si  is  0), 
and  for  all  j  <  n  and  j  /  i. 

y:i  —  ((0,  0,  0),  (Pe[ej]  ehnp)(2))-  /*  Other  parameters  are  not  interesting  objects  */ 
The  result  of  the  local  improved  refined  escape  test  function  is  interpreted  as  follows: 

•  If  L_irescape?(/,  en,  envp)  =  (0,  0)  then  we  can  conclude  that  in  the  particular 

application  of  /  to  gj  through  en,  none  of  the  ith  argument  escapes  /. 

•  If  LJrescape?(/,  i,  ei, . . . ,  en,  envp)  —  (1,  k)  then  we  can  conclude  that  if  s;  >  1  then, 
in  the  particular  application  of  /  to  e\  through  en ,  the  top  (s2-  —  A:)  spines  of  the  ith 
argument  do  not  escape  /,  but  the  bottom  k  spines  could  escape  /.  If  Si  =  0  then  the 
jth  argUmellt_  which  is  not  a  list  type,  could  escape  in  the  particular  application  of  / 
to  e\  through  en. 

3.4  Comparison  to  Escape  Analysis  and  Complexity 

The  refined  escape  semantics,  the  abstract  refined  escape  semantics,  and  the  improved  ab¬ 
stract  refined  escape  semantics  with  some  d  >  0  provide  more  refined  escape  information 
than  the  escape  semantics,  the  abstract  escape  semantics,  and  the  improved  abstract  escape 
semantics,  respectively.  The  relationship  among  the  standard  semantics,  the  escape  se¬ 
mantics,  the  improved  abstract  escape  semantics,  the  abstract  escape  semantics,  the  refined 
escape  semantics,  the  improved  abstract  refined  escape  semantics,  and  the  abstract  refined 
escape  semantics  is  shown  in  Figure  3.10. 

The  abstract  interpretation  framework  for  the  refined  escape  analysis  is  the  same  as  that 
for  the  escape  analysis  presented  in  the  previous  chapter  except  for  the  size  of  the  abstract 
basic  domain.  While  the  escape  analysis  uses  a  two-element  domain,  the  refined  escape 
analysis  uses  a  (d  +  2)-element  domain  where  d  is  fixed  and  greater  than  2.  Thus,  the  order 
of  worst-case  time  complexity  of  refined  escape  analysis  is  higher  than  but  is  comparable  to 
that  of  escape  analysis,  which  is  exponential. 
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Figure  3.10:  Relationship  among  Escape  and  Refined  Escape  Semantics 
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Chapter  4 


Reference  Escape  Analysis 


In  reference  counting  schemes  for  automatic  storage  reclamation,  each  time  a  reference  to 
an  object  is  created  or  destroyed,  the  reference  count  of  the  object  needs  to  be  updated. 
This  may  involve  expensive  inter-processor  message  exchanges  in  distributed  environments. 
In  higher-order  functional  languages,  exact  information  about  the  lifetime  of  a  dynamically 
created  reference  to  a  heap- allocated  object  is  generally  unknown  at  compile-time.  Thus, 
updating  on  the  reference  count  of  the  object  is  performed  whenever  a  reference  to  the 
object  is  created  and  destroyed.  Such  information,  if  inferred  at  compile-time,  could  be 
useful  for  improving  the  reference  counting  scheme  for  both  uniprocessor  and  multiprocessor 
environments. 

In  this  chapter,  we  present  a  method  for  computing,  at  compile-time,  safe  information 
about  the  relative  lifetimes  of  dynamically  created  references  to  objects,  such  as  arguments 
and  local  objects  defined  within  a  function,  with  respect  to  the  lifetime  of  the  function  call. 
As  before,  the  language  we  consider  is  a  higher-order,  monomorphic,  and  strict  functional 
language.  This  method  is  based  on  a  compile-time  semantic  analysis  called  reference  escape 
analysis.  First,  we  introduce  a  non-standard  denotational  semantics  called  reference  escape 
semantics  that  describes  the  actual  reference  escape  behavior,  but  is  incomputable  at  com¬ 
pile  time.  An  abstraction  method  of  approximating  the  exact  reference  escape  semantics 
which  is  safe  with  respect  to  the  exact  reference  escape  semantics  and  is  computable  at 
compile-time  is  then  presented.  Based  on  the  abstract  reference  escape  semantics  and  func¬ 
tion  transformation,  we  describe  the  reference  escape  testing  algorithms  which  determine 
reference  escape  information.  Another  safe  and  computable  abstraction  of  the  exact  ref¬ 
erence  escape  semantics  called  improved  abstract  reference  escape  semantics  that  improves 
the  precision  of  reference  escape  information  using  the  position  information  of  objects  in  a 
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Figure  4.1:  Escapement  of  References 

list  structure  is  also  presented.  Finally,  the  complexity  of  the  reference  escape  analysis  is 
discussed. 

4.1  Escapement  of  References 

An  object  needed  in  more  than  one  place  during  a  program’s  execution  is  typically  handled 
in  one  of  two  ways:  either  the  object  itself  is  copied  or  a  pointer  to  the  object  is  copied.  We 
describe  the  operational  model  in  which  references  are  created  and  destroyed.  We  choose  a 
model  that  is  commonly  implemented  in  LISP  and  functional  language  systems,  that  of  a 
call  by  value  language  with  pointer  semantics  for  heap  allocated  structures.  References  are 
created  in  three  ways: 

1.  When  a  heap  allocated  object  is  created,  a  reference  to  that  object  is  created  and 
returned  by  the  allocation  procedure  (e.g.  cons). 

2.  When  a  heap  allocated  object  is  passed  as  a  parameter  in  a  function  call,  a  reference 
to  the  object  is  copied  into  the  activation  record  of  the  called  function. 

3.  When  an  assignment  occurs  (in  a  letrec,  for  example),  and  the  value  of  the  right  hand 
side  is  a  heap- allocated  object,  a  reference  to  the  object  is  copied  into  the  variable  (or 
record  held)  on  the  left  hand  side. 

Consider  the  following  function  definition: 

f  x  y  =  letrec  g  a  b  =  cons  a  b 
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in  cons  x  (g  x  y) 

When  f  is  called,  its  activation  record  contains  two  references  to  lists,  corresponding  to  the 
parameters  x  and  y.  Thus,  when  (g  x  y)  is  evaluated,  the  references  corresponding  to  x 
and  y  are  copied  into  the  activation  record  for  g.  Likewise,  any  argument  to  cons  that  is 
represented  by  a  reference  is  also  copied. 

We  analyze  the  lifetimes  of  a  reference  by  determining  its  escapement ,  that  is,  whether 
or  not  a  reference  is  returned  out  of  the  scope  in  which  it  was  created.  When  does  a 
reference  escape?  Intuitively,  a  reference  can  escape  when  it  is  placed  in  a  structure,  or 
closure  that  escapes.  If  a  reference  does  not  escape  the  scope  of  its  creation,  no  reference 
counting  operations  are  necessary  when  the  reference  is  created  or  destroyed.  In  the  above 
example,  when  the  references  corresponding  to  x  and  y  are  copied  into  g’s  activation  record, 
no  reference  count  increment  operation  is  required.  Likewise,  when  g  returns,  no  decrement 
operation  is  required.  However,  when  a  cons  cell,  corresponding  to  (cons  a  b),  is  created, 
the  reference  counts  of  the  objects  pointed  to  by  a  and  b  must  be  incremented.  This  is 
because  the  lifetime  of  the  cons  cell  exceeds  that  of  g  and  f ,  and  it  cannot  be  determined 
at  compile  time,  when  the  references  contained  in  the  cons  cell  will  be  destroyed. 

We  formally  define  the  notion  of  escapement  of  references,  and  illustrate  it  in  Figure  4.1. 

Definition  4.1  (Global/Local  Reference  Escapement)  Given  a  function  /  with  n  for¬ 
mal  parameters  and  m  locally  defined  objects,  the  jth  occurrence  of  the  ith  parameter  or 
locally  defined  object  is  said  to 

•  reference-escape  the  function  call  to  /  globally  if,  in  some  possible  application  of  /  to 
n  arguments,  the  reference  associated  with  X{  outlives  the  the  function  call  (by  being 
contained  in  the  result  of  the  function  application). 

•  reference-escape  the  function  call  to  /  locally  in  (/  ej  ...  en )  if,  in  the  particular 
function  application  of  (/  e%  ...  en),  the  reference  associated  with  Xi  outlives  the 
activation  of  the  function  call. 

From  the  escapement  of  a  reference  with  respect  to  its  defining  function,  we  can  deduce 
its  lifetime:  If  the  reference  associated  with  an  occurrence  of  a  parameter  or  local  object 
does  not  escape  the  function  call  globally  then  we  can  conclude  that  the  lifetime  of  the 
reference  is  confined  to  the  lifetime  of  any  possible  call  to  the  function.  Similarly,  if  it  does 
not  reference-escape  the  function  call  locally  in  a  particular  function  application  then  we 
can  conclude  that  the  lifetime  of  the  reference  is  confined  to  the  lifetime  of  that  particular 
function  call. 


75 


We  will  develop  a  general  method  for  higher-order,  monomorphic,  strict  functional  lan¬ 
guages  to  answer  the  following  questions  at  compile-time: 

•  Given  a  function  and  an  occurrence  of  a  parameter  or  local  object,  does  the  reference 
associated  with  the  occurrence  reference-escape  the  function  call  globally  ? 

•  Given  a  function  in  a  particular  application  context  and  an  occurrence  of  a  parameter 
or  local  object  that  is  defined  within  the  function,  does  the  reference  associated  with 
the  occurrence  reference-escape  that  function  call  ? 

4.2  Function  Transformation 

In  order  to  make  each  occurrence  of  each  parameter  of  a  function  distinct,  we  introduce  an 
auxiliary  function  ['  for  each  function  /.  Then,  we  perform  reference  escape  testing  on  f 
to  determine  reference  escape  property  of  each  occurrence  of  each  parameter  of  /.  Given  a 
function 


f  xL  ...  xn  =  e, 

the  auxiliary  function  f  is  given  as  follows: 

f  ^11  •  •  •  ^  nl  •  •  •  ^ 

where  o(i)  is  the  number  of  occurrences  of  xt  in  e  and  e'  is  derived  from  e  by  replacing  the 
jth  occurrence  of  Xi  by  x l;;  for  all  i  and  j.  Note  that  each  parameter  of  f  will  now  have 
only  one  occurrence,  and  f  will  be  never  called  from  anywhere  and  thus  is  not  recursive. 
To  determine  the  escape  behavior  of  references  associated  with  occurrences  of  parameters 
of  /,  we  perform  the  test  on  its  auxiliary  function  f.  For  example,  consider  the  following 
function. 

f  x  y  =  letrec  g  a  b  =  cons  a  b; 
in  cons  x  (g  x  y) 

An  auxiliary  function  f  ’  derived  from  f  is  given  as  follows: 

f’  xl  x2  y  =  letrec  g  a  b  =  cons  a  b; 

in  cons  xl  (g  x2  y) 
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Figure  4.2:  The  Basic  Reference  Escape  Domain 

4.3  Exact  Reference  Escape  Semantics 

We  introduce  an  exact  but  uncomputable  non-standard  denotational  semantics,  called  ref¬ 
erence  escape  semantics ,  which  describes  the  complete  escaping  behaviors  of  references  for 
functions  in  a  program.  The  reference  associated  with  each  occurrence  of  a  parameter  or 
local  object  will  be  analyzed  separately  to  determine  its  reference-escape  behavior.  We 
say  that  a  reference  is  interesting  if  it  is  the  one  whose  escape  behavior  we  are  trying  to 
determine.  Thus,  our  reference  escape  semantics  is  defined  in  terms  of  a  single  interesting 
reference. 

Representing  Reference  Escape  Information 

The  meaning  we  will  attach  to  the  syntax  of  our  language  is  information  about  escaping 
references.  For  each  expression,  we  want  its  corresponding  value  in  the  reference  escape 
semantic  domain  to  be  able  to  tell  us  if  an  interesting  reference  is  not  contained  in  the  value 
of  the  expression  (“non- reference- escape”),  or  if  an  interesting  reference  is  contained  in 
the  value  of  the  expression  (“reference-escape”).  Under  the  non-standard  reference  escape 
semantics,  we  represent  the  meaning  of  an  expression  as  a  pair,  called  a  reference  escape 
pair , 

1.  whose  first  element  denotes  the  containment  of  an  interesting  reference  in  the  value 
of  the  expression,  and 

2.  whose  second  element  denotes  the  functional  behavior  of  the  expression  defined  over 
the  reference  escape  domain  when  the  expression  itself  is  applied  to  another  expression. 

For  a  non-list  type  expression,  the  corresponding  value  in  the  non-standard  reference  escape 
semantic  domain  Dr  has  two  components;  The  first  component  is  an  element  of  a  domain 
called  a  basic  reference  escape  domain ,  Br  which  is  a  two  element  domain  showned  Fig- 


77 


ure  4.2.  The  ordering  is  defined  as  0  C  1.  The  interpretation  of  elements  of  II,  is  defined 
as  follows: 

•  1  :  An  interesting  reference  is  contained  in  the  value  of  the  expression. 

•  0  :  No  interesting  reference  is  contained  in  the  value  of  the  expression. 

For  expressions  which  have  no  higher-order  behavior,  err  which  is  a  function  that  can  never 
be  applied,  is  used.  For  a  list  type  expression,  the  corresponding  value  in  the  reference 
escape  semantic  domain  is  a  list  that  consist  of  corresponding  reference  escape  values  of  its 
components. 


Reference  Escape  Semantic  Domains 


The  reference  escape  semantic  domain  Dr  and  the  domain  Er  of  reference  escape  environ¬ 
ments  are  defined  as  follows: 


Dr  =  ^ D  ‘,  /*  Reference  escape  semantic  domain  */ 

Er  =  Id  —  Dr  /*  Domain  of  reference  escape  environments  */ 


The  reference  escape  domain  Dr  is  a  sum  domain  consisting  of  each  subdomain  for  each 
type.  The  reference  escape  subdomain  D }  for  expressions  of  type  r  is  defined  as  follows: 


r)int 

±sr 

reboot 

-L/r 

jjt  list 


Br  X  {err}  subdomain  for  integers 

Br  X  {err}  subdomain  for  booleans 

Br  X  {  D}1  — »■  D}2  )  subdomain  for  functions  of  type  T\  — >  T2 

(Br  X  {err})  +  (D{  X  hst )  subdomain  for  lists  of  type  r  list 


Reference  Escape  Semantic  Functions 

The  non-standard  reference  escape  semantic  functions  are  defined  as  follows: 

Rc  :  Con  — ►  Dr  /*  Reference  escape  semantic  function  for  constants  *  j 

R,  :  Exp  — »■  Er  —  Dr  j*  Reference  escape  semantic  function  for  expressions  */ 

Rpr  :  Program  -h*  Dr  /*  Reference  escape  semantic  function  for  programs  */ 

The  semantic  equations  for  the  reference  escape  semantic  functions  are  expressed  in  Fig¬ 
ure  4.3.  Note  that  Oracle  is  used  to  resolve  the  exact  behavior  of  the  conditional  expression 
if,  which  relies  on  the  standard  semantics.  envr  is  any  exact  reference  escape  environment 
in  Et,  and  nullenvr  is  a  reference  escape  environment  that  maps  every  identifier  on  to  the 
least  element  of  its  reference  escape  domain. 
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RM  =  (0 ,  err) ,  c  £  1,  0, 1, true,  false, nilT  hst} 

i?e[cons]  =  (0,  Aa.(a(1),  Ap.  pair(x,  j/))) 

i?c[car]  =  (0,  Aa.  first(a)) 

i?c[cdr]  =  (0,  Aa.  second(a)) 

i?c[null]  =  (0,  Aa.(0,  err)) 

R,  [<•]<  nr,.  =  Rc{cj 

Re[x\envf  =  enur[a] 

Re\e i  +  e2 Jenvr  =  (0 ,err)  /*  same  for  —  e-i  and  e\  =  e2  */ 

i?e[ if  ei  then  e-i  else  e^\envr  =  if  Oracle(ei)  then  {Re\e2\envr) 

else  ( Re\e2\envr) 

Reiele2jenvr  =  (  R,  ['  1  1'  nvr  )(2)  ( Re^jenVr  ) 

i?e[lambda(a).e]erin7.  =  (Fr,  Af/.i?e[e]erinr[a  j/]) 

where 

V  —  (0,  0)  U  (  y  (ent7r[z])(1))  U  (  |J  (  [J  p(1))), 

z£pnon-list  z£Fliet  pineS»r[z] 

p  in  erinr[2])  denotes  that  p  is  an  reference  escape  pair  in  en«r[^], 
jpnon-hst  _  ge^  Qj-  ILOIL_|]s[  type  free  identifiers  in  (lambda(a).e),  and 
Flist  =  Set  of  hst  type  free  identifiers  in  (lambda(a).e). 

i?e[letrec  x\  =  e\  \ . . . ;  xn  =  e„;  in  e] envr  =  i?e[e]erin' 

where  env'r  =  enay  [ai  i— ►  i?e[ei]eria>' , . . . ,  xn  hh>  RelenJenv'r\ 

Rpr\l}rJ  =  Re\pr\nullenvr 

Figure  4.3:  Reference  Escape  Semantic  Functions 
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<M> 


(1,1) 

(1,0) 

(0,0) 


Figure  4.4:  The  Abstract  Basic  Reference  Escape  Domain 

4.4  Abstract  Reference  Escape  Semantics 

We  present  a  safe  and  computable  abstraction  of  the  exact  reference  escape  semantics  de¬ 
fined  in  the  last  section  that  allows  an  approximation  of  the  exact  reference  escape  behavior 
for  functions  to  be  found  at  compile-time. 

Abstracting  Reference  Escape  Domains 

We  safely  approximate  the  exact  reference  escape  semantics  by  abstracting  the  reference 
escape  semantic  subdomains  for  list  type  expressions,  and  by  approximating  the  reference 
escape  semantic  functions.  For  each  expression,  its  corresponding  value  in  the  abstract  ref¬ 
erence  escape  semantic  domain  tells  us  if  an  interesting  reference  is  definitely  not  contained 
in  the  value  of  the  expression  ( “non-reference-escape”),  or  if  an  interesting  reference  may  be 
contained  in  the  value  of  the  expression  (“possible  reference-escape”).  The  abstract  basic 
reference  escape  domain  is  shown  in  Figure  4.4.  The  ordering  is  defined  as  follows: 

(0,0)C(1,0)C(1,1)C...C(1  ,h) 

The  interpretation  of  the  elements  of  Br  is  defined  as  follows: 

•  (1,  j)  :  An  interesting  reference  may  be  contained  in  the  value  of  the  expression,  and 
if  j  >  1  then  it  is  a  reference  to  the  cons  cell  at  the  bottom  jth  spine  of  a  list.  (If 
j  —  0  then  the  object  pointed  to  by  the  interesting  reference  is  not  a  cons  cell.) 
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•  (0,  0)  :  No  interesting  reference  is  contained  in  the  value  of  the  expression. 

The  abstraction  of  the  reference  escape  semantic  subdomains  for  list  type  expressions  is 
done  by  representing  lists  as  finite  objects,  i.e.  by  combining  the  escape  pairs  of  all  its 
elements  into  a  single  escape  pair.  The  abstract  reference  escape  semantic  domain  Dr  and 
the  domain  Er  of  abstract  reference  escape  environments  are  defined  as  follows: 

Dr  =  /*  Abstract  reference  escape  semantic  domain  */ 

Er  =  Id  —  Dr  /*  Domain  of  abstract  reference  escape  environments  */ 

The  abstract  reference  escape  subdomain  I)}  for  expressions  of  type  r  is  defined  as  follows: 

jjint  —  Br  x  {err}  abstract  subdomain  for  integers 

Dbr°°l  =  Br  X  {err}  abstract  subdomain  for  booleans 

D}1^T2  =  Br  X  (D}1  — >  DTr2  )  abstract  subdomain  for  functions  of  type  T\  — >  T2 

jjr  list  _  jjt  abstract  subdomain  for  lists  of  type  r  list 

Abstracting  Reference  Escape  Functions 

The  abstract  reference  escape  semantic  functions  are  defined  as  follows: 

Rc  :  Con  — >  Dr  /*  Abstract  reference  escape  function  for  constants  */ 

Re  :  Exp  —r  Er  — >  Dr  /*  Abstract  reference  escape  function  for  expressions  */ 

Rpr  :  Program  —  Dr  /*  Abstract  reference  escape  function  for  programs  */ 

The  abstract  reference  escape  semantic  functions  are  given  in  Figure  4.5.  The  abstract  value 
of  cons  returns  a  single  reference  escape  pair  that  approximates  a  list  of  reference  escape 
pairs  by  taking  the  least  upper  bound  of  its  two  arguments.  The  cars  denotes  a  car  that  is 
applied  to  a  list  with  s  spines.  For  each  car  in  a  program,  s  can  be  determined  statically  by 
type  checking.  It  may  be  arbitrary  large,  but  is  fixed  at  compile-time.  The  abstract  value 
of  car  is  defined  as  follows:  cars  takes  a  list  with  s  spines  as  an  argument,  and  returns  a 
list  with  (s  —  1)  spines  when  s  >  1  or  a  non- list  object  when  s  =  1.  In  either  case,  the  result 
cannot  contain  an  interesting  reference  pointing  to  the  cons  cells  at  the  bottom  sth  spine  of 
a  list.  The  abstract  value  of  cdr  just  returns  its  argument.  envr  is  any  abstract  reference 
escape  environment  in  Er,  and  nullenvr  is  an  abstract  reference  escape  environment  that 
maps  every  identifier  to  the  least  element  of  its  abstract  reference  escape  semantic  domain. 

Safety  and  Termination 

The  safety  of  interpretation  under  the  abstract  reference  escape  semantics  can  be  proved  as 
follows.  Let  u  and  v  be  values  of  an  expression  e  of  type  r  in  the  abstract  reference  escape 
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Rc[c\  =  ((0,  0),  err),  c  ={...,  — 1, 0, 1, true,  false} 

^Rcjnil7  h,st]  =  J_T  (  The  bottom  element  in  DJ..) 

Ecjcons]  =  ((0,0),\x.(x^,\y.xUy)) 

.Rcjcar3]  =  ((0,  0),  Aa.cuts(a)) 

where  cuts(2:)  =  if  —  s)  then  ((0,  0),  @(2))  else  z 

Ecfcdr]  =  ((0, 0),  Aa.a) 

Ecjnull]  =  ((0,0),  Xx. ((0,0), err)) 

RelcjefiVr  =  -Rc[c] 

Re\x\ehvT  =  erarr[a] 

i?e[e i  +  e2 Jenvr  =  ((0,0),  err)  /*  same  for  e\  —  e2  and  e\  =  e2  */ 

Re\ if  ej  then  e2  else  e^\envT  =  (  Reie2Jenvr)  U  ( Rele2Jenvr) 

Releie2}envr  =  (Releijenvr)^  (Rele2}envr) 

i?e[lambda(a).e]efirr  =  (F,  A y.Re\e\ehvr[x*-?  y\) 

where 

V  -  (0,  0)  U  (  | _ |  (emvMI)^))  and 

F  =  Set  of  free  identifiers  in  (lambda(a).e). 

i?e[letrec  x1  =  e1; . . . ;  xn  =  en;  in  e\envr  =  Rf\e\env'r 

where  ehv'r  =  ehvr\x j  _Re[ei]enrf, , . . ,  xn  i— >  i?e[en]eh«(,] 

RprlprJ  =  Re\pr\nullenvT 

Figure  4.5:  Abstract  Reference  Escape  Semantic  Functions 
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domain  Dr  and  the  exact  reference  escape  domain  Dr,  respectively.  Let  n  be  the  number 
of  arguments  that  the  type  r  can  take  before  returning  a  value  of  primitive  type.  We  say 
that  the  abstract  reference  escape  semantic  value  a  is  a  safe  approximation  (with  respect 
to  reference  escape  information)  for  the  exact  reference  escape  semantic  value  v  iff 

(  U  P(l))  E  (NAP*  (ri,Sl3>-  .  - ,  «*)}(!)(!) 

p  in  NAP*(-u,ti,...,fA) 

for  all  k  <  n  where  s;  is  a  safe  approximation  for  lt  for  all  i  <  k. 

Theorem  4.1  (Safety)  For  any  expression  e,  and  environments  envT  and  ehvT  such  that 
for  all  y,  entyjt/]  is  safe  for  envr\y\,  Re\e\efivr  is  safe  (with  respect  to  reference  escape 
information)  for  Re\e\envr. 

Proof  :  We  can  prove  by  structural  induction  on  expression  e. 

I.  Base  Case: 

1.  e  =  c:  Re\c\ehvT  =  i?c[c]  and  Re\c\envr  =  i?c[c].  For  c£  {. . .  ,-1,0,1,. . .  ,  true, 
false,  nil,  null  }  ,  i2c[c]  =  f?c[c]  and  thus  it  clearly  holds.  For  c  =  cons,  it  holds 
because  if  xp  and  X2  are  safe  for  yi  and  p2 ,  respectively,  then  x\  U  X2  is  also  safe  for  a  list 
consisting  of  yi  and  3/2  -  If  holds  for  c  =  cars,  because  if  x  is  safe  for  y  then  cuts(r)  is 
safe  for  first(?/).  It  holds  for  c  =  cdr,  because  if  x  is  safe  for  y  then  x  is  clearly  safe  for 

second(t/). 

2.  e  =  x\  Re\x\ehvT  =  ehrr[x-]  and  Re\x\envr  =  eriur[a-].  Since,  for  all  y ,  ehrr[y]  is 
safe  for  envrfyj,  it  clearly  holds. 

II.  Structural  Induction  Step:  Assume  that  Re\e\ehvr  is  safe  for  Re\e\envr  for  expres¬ 

sions  such  as  (q.  ex.  C'2 ,  e,3  and  en.  (structural  induction  hypothesis)  Then,  we  show  that 
Re\e\ehvr  is  safe  for  Re\e\envr  for  e\  +  e2,  if  ei  then  e2  else  e  =  e^,  lainbda(a).ei 
and  letrec  a’i  =  . . . ;  xn  =  en\  in  eo-  This  can  be  proved  in  the  same  way  as  the  safety 

proof  of  the  abstract  escape  semantics  with  respect  to  the  exact  escape  semantics.  □ 

Theorem  4.2  (Termination)  For  any  (finite)  program  pr  6  Program,  Rf,r [pr]  is  com¬ 
putable. 

Proof  :  Every  functional  in  the  reference  escape  domain  that  is  defined  by  the  abstract 
reference  escape  semantic  functions  is  composed  of  the  operators  such  as  the  least  upper 
bound  operator  U  and  cuts,  which  are  all  monotonic.  As  before,  each  subdomain  D)  is 
finite.  □ 
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4.5  Reference  Escapement  Testing 


Reference  escape  analysis  will  determine  for  a  function  the  relative  lifetime  of  the  reference 
associated  with  a  bound  variable  with  respect  to  references  associated  with  its  occurrences. 
We  perform  reference  escape  analysis  on  each  occurrence  of  each  argument  of  a  function 
call  separately.  Thus,  at  any  time  we  are  only  interested  in  whether  or  not  a  particular 
single  occurrence  of  a  particular  variable  escapes.  Other  objects  may  escape  in  the  result  of 
a  function  call,  but  are  ignored  by  our  analysis  model.  An  occurrence  is  interesting  if  it  is 
the  one  whose  escape  behavior  we  are  trying  to  determine.  If  a  variable  has  n  occurrences, 
then  reference  escape  analysis  will  be  performed  n  times,  each  time  treating  a  different 
occurrence  as  interesting. 

Consider  the  example  from  before: 

f  x  y  =  letrec  g  a  b  =  cons  a  b 
in  cons  x  (g  x  y) 

As  we  discussed  previously,  each  occurrence  of  x  in  the  body  of  f  denotes  the  creation  of 
a  new  reference.  To  differentiate  between  the  occurrences  of  x,  we  label  each  occurrence 
differently.  In  fact,  the  different  occurrences  can  be  considered  different  parameters  to  the 
auxiliary  function  derived  from  f: 

f’  xl  x2  y  =  letrec  g  a  b  =  cons  a  b 
in  cons  xl  (g  x2  y) 

Our  abstract  reference  escape  semantics  will  give  the  escapement  of  the  parameters  to  f  ’ , 
and  thus  of  the  references  corresponding  to  xl  and  x2.  We  describe  below  how  this  analysis 
proceeds. 

Global  Reference  Escape  Test 

Given  a  function  /  x\  ■  ■  ■  xn  =  bodyf  of  arity  n ,  the  position  ( i.  j)  of  an  interest¬ 
ing  reference  of  a  parameter,  and  an  abstract  reference  escape  semantic  environment  envT 
mapping  /  to  an  element  of  D,r.  the  global  reference  escape  test  function  G_refescape?  de¬ 
termines  whether  the  reference  associated  with  the  jth  occurrence  of  the  ith  parameter  of  / 
could  escape  /  globally.  It  is  defined  as  follows: 

G_refescape?  ( /,  i,  j,  ehi y )  = 

1  •  •  •  ic/fl )  *  *  *  '  '  '  *^no(ri)J  Cn'Dy  [f  I  >  f  ,  X{j  I  -  )  (1)  (1) 
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where  f  is  the  auxiliary  function  for  /, 

/'  =  Relf’jenvr, 

yij  =  ((1,  Sj),  WTi),  /*  The  jth  occurrence  of  ith  parameter  is  interesting  */ 

Si  is  the  number  of  spines  of  the  ith  parameter  of  /  (if  it  is  a  list  type,  otherwise  Si  is  0), 
for  all  k  <  o(i )  and  k  ^  j, 

yik  =  ((0,  0),  WTi),  /*  Other  occurrences  of  ith  parameter  are  not  interesting  */ 
and  for  all  1  <  m  <  o(  l)  and  l  i, 

yim  =  ((0,  0),  WTl),  /*  Occurrences  of  other  parameters  are  not  interesting  */ 

and  T.,  is  the  type  of  the  ith  parameter  of  /.  Only  the  reference  associated  with  the  jth  occur¬ 
rence  of  the  ith  parameter  is  interesting  reference,  and  the  references  associated  with  other 
occurrences  of  the  ith  parameter  are  not  interesting.  Similarly,  the  references  associated 
with  all  occurrences  of  parameters  other  than  the  ith  parameter  are  also  not  interesting.  In 
order  to  represent  the  functional  behavior  of  all  possible  expressions  that  could  be  the  ith 
argument  to  /,  the  worst-case  behavior  is  taken.  From  the  result  of  the  global  reference 
escape  test  function,  we  can  conclude  the  following: 

•  If  G_refescape?(/,  i,  j,  efivr)  =  0  then  we  conclude  that  the  reference  associated  with 
the  jth  occurrence  of  the  ith  argument  does  not  escape  the  function  call  to  /  in  any 
possible  application  of  /  to  n  arguments. 

•  If  G_refescape?(  /,  i,  j,  envr  )  =  1  then  it  means  that  the  reference  associated  with  the 
jth  occurrence  of  the  ith  argument  could  escape  the  function  call  in  some  possible 
application  of  /  to  n  arguments. 

Local  Reference  Escape  Test 

Given  a  function  f  x \  X2  ■  ■  ■  xn  =  bodyj  of  arity  n  in  a  particular  function  application 
f  e i  ...  en,  the  position  (i,j)  of  an  interesting  reference  of  a  parameter,  and  an  abstract 
reference  escape  semantic  environment  envr  mapping  /  and  free  identifiers  within  ei  through 
en  to  elements  of  l)r,  the  global  reference  escape  test  function  L_refescape?  determines 
whether  the  reference  associated  with  the  jth  occurrence  of  the  ith  parameter  of  /  could 
escape  /  globally.  It  is  defined  as  follows: 
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L_refescape? (/,  i,  y,  e1; . .  .,en,envr)  = 

X1  ■  ■  ■  -Clofl)  •  •  •  xn  •  •  •  xno(n)1  £flVT\f  I  *  I  ^  2/i J ] ) (1 ) (1) 

where  f  is  the  auxiliary  function  for  /, 

/'  =  Relfjenvr, 

Vij  =  (^e[e2]efiur)(2))5 

Si  is  the  number  of  spines  of  the  ith  parameter  of  /  (if  it  is  a  list  type,  otherwise  Si  is  0), 
for  all  k  <  o(i )  and  k  ^  j, 

Vik  =  ((0,0),  (Relet}enVr)(2)}, 

for  all  1  <  m  <  o(/)  and  l  ^  i, 

Vim  =  ((0,0),  ( . 

Then,  from  the  result  of  the  local  reference  escape  test  function,  we  can  conclude  as  follows: 

•  If  L_refescape?(/,  i.  j ,  c j , . . . ,  ev .  envr)  =  0  then  we  conclude  that  the  reference  associ¬ 
ated  with  the  jth  occurrence  of  the  ith  argument  does  not  escape  the  function  call  to 
/  in  (/  et...  en). 

•  If  L_refescape?(/,  i,j,  e1, . . . ,  en,  envr  )  =  1  then  it  means  that  the  reference  associated 
with  the  jth  occurrence  of  the  ith  argument  could  escape  the  function  call  (/  e1  . . .  en). 

Examples 

As  an  example,  consider  a  program  defined  as  follows: 

letrec  map  f  1  =  if  (null  1)  then  nil 

else  cons  (f  (car  1))  (map  f  (cdr  1)); 

sum  1  =  if  (null  1)  then  0 

else  (car  1)  +  sum  (cdr  1) ; 


in 


addsum  x  y  =  cons  x  (cons  y  (cons 

(map  (lambda (z ) .  (sum  y)  +  z)  x)  nil)); 


We  assume  that  the  type  of  each  function  is  given  by 
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map  :  (int  — >  int )  — >  int  list  — >  ini  list 
sum  :  int  list  — ►  int 

addsum  :  int  list  — >  int  list  — *  (int  list)list 

From  type  checking,  each  car  in  the  program  can  be  annotated  as  follows: 

map  f  1  =  if  (null  1)  then  nil 

else  cons  (f  (CAR1  1))  (map  f  (cdr  1)); 

sum  1  =  if  (null  1)  then  0 

else  (CAR1  1)  +  sum  (cdr  1) ; 

where  CARi  denotes  a  car  that  takes  as  its  argument  a  list  with  i  spines.  The  definitions 
of  the  reference  escape  semantic  values  of  map,  sum,  and  addsum  are  as  follows: 

map  f  l  =  ((0,  0),  err)  U  ( /(2)  (cut1^)),  /(2)})  □  ((map^  /)(2)  l ) 

sum  l  =  ((0,0),  err)  U  ((0,  0),  err) 

addsum  x  y  =  x  U  y  U  ((map^)  (y(i),  Az.((0,  0),  err)))(2)  x) 

Since  map  is  defined  recursively,  the  meaning  of  map  is  found  by  a  fixpoint  iteration: 

map1'0')  f  l  =  ((0,0)  ,  err) 

map W  /  l  =  ((0,  0),  err)  U  ( /(2)  (cut1(/(1)),  /(2)))  U  ((map|°j  /)(2)  l ) 

=  /(2)  <CUt1(/|i)),/(2)) 

mapW  f  l  =  ((0,  0),  err)  U  ( /(2)  (cutx(/(1)),  l(2)))  U  ((mapfy  /)(2)  l ) 

—  /(2)  (clit1(/^i)), /(2)) 

Since  map W  =  map^2\  we  have  that 

map=  ((0,0),  A/.(/(1),  AZ./(2)  <cut1(Z(1)),  /(2)>)) 

addsum  x  y  =  m  U  j/  U  ((raap(2)  (?/(i),  Az.((0,  0),  err)):)(;2)  m) 

=  iUj/  U  (Az.((0,0),err))  (cut1^^),  z(2)) 

=  x  U  y  U  ((0,  0),  err) 

=  iUj/ 

The  auxiliary  functions  map'  and  addsum’  for  map  and  addsum  are  defined  as  follows: 

map’  fl  f 2  11  12  13  =  if  (ll=nil)  then  nil 

else  cons  (fl  (car  12)) 

(map  f2  (cdr  13)); 


87 


addsum’  xl  x2  yl  y2  =  cons  xl  (cons  yl 

(cons  (map  (lambda (z) . (sum  y2)+z)  x2)  nil)); 

Note  that  map’  is  not  recursively  defined.  The  definitions  of  the  reference  escape  semantic 
values  of  map’,  and  addsum’  are  given  as  follows  (without  a  fixpoint  iteration): 

map'  fl  /2  11  12  13  =  ((0,  0),  err)  U  (/1(2)  (cut1(/2(1)),  Z2(2)))  U  (( map (2)  /2)(2)  Z3) 

=  ((().  0),  (  /'/•)  U  (/I  (2)  (cut1(/2(1)),  /2(2)}) 

U(/2(2)  (cut1(Z3(1)),Z3(2))) 

addsum'  xl  x2  yl  y 2  =  xl  U  yl 

Let  ehvr  =  [map  i-»  map ,  add  add ,  addsum  h- >  addsum ].  Then, 

G_refescape?( addsum,  1, 1,  ehvr)  =  (  /£t[  adds  urn’  xl  x2  yl  y2]enr/,.)(i)(i) 

=  1 

where  env'T  =  envr  [addsum’  addsum', x  1  ((1, 1),  err),  x2,  yl,  y2  ((0,  0),  err)]. 

Thus,  we  can  conclude  that  the  reference  associated  with  the  first  occurrence  xl  of  the 
first  parameter  x  of  addsum  escapes.  And, 

G_refescape?(addsum,  1,  2,  ehvr)  =  ( i2e[addsum’  xl  x2  yl  y2]erir/r)(1)(1) 

=  0 

where  env'r  =  ehrr[addsum’  i-»  addsum',  x2  ((1, 1),  err),  xl,  yl,  y2  i-»  ((0,  0),  err)]. 
Thus,  we  can  conclude  that  the  reference  associated  with  the  second  occurrence  x2  of 
the  first  parameter  x  of  addsum  does  not  escape. 

G_refescape? (addsum,  2, 1, ehvr)  =  (i?e[addsum'  xl  x2  yl  y2\env' r) 

=  1 

where  env'r  =  eric,, [addsum’  i— >  addsum',  yl  >->■  ((1, 1),  err),  xl,  x2,  y2  i— >  ((0,  0),  err)]. 

G_refescape?(addsum,  2,  2,  ehvr)  =  (i?e[addsum’  xl  x2  yl  y2]enr/7.)(i)(i) 

=  0 

where  env'r  =  envr  [addsum’  addsum',  y2  ((1, 1),  err),  xl,  x2,  yl,  s-*  ((0,  0),  err)]. 
Thus,  similarly,  we  can  conclude  that  the  reference  associated  with  the  first  occurrence  yl 
of  the  second  parameter  y  of  addsum  escapes,  but  the  reference  associated  with  the  second 
occurrence  y2  of  the  second  parameter  y  of  addsum  does  not  escape. 


G_refescape?(map,  1, 1,  ehvr) 


=  (i?e[map  ’  fl  f 2  11  12  13]ent7'r)(i)(i) 

=  0 

where 

env'r  =  ef^^7r[map,  map',  fl  ((1,  0),  Az.^^,  err)), 

f  2  i  *  ((0,  0),  Ax.(a|  |  j.  err)),  11, 12, 13  i— *  ((0,  0),  err)]. 

and 

G_refescape?(map,  1, 2,  ehvr)  =  (i^elmap’  fl  f2  11  12  13]erirV)(i)(i) 

=  0 

where 

env'r  =  envr\nna.p'  hh>  map',  fl  i— >  {{().  0).  A;:. {£(,),  err)), 

f2~  «1,0),  Az^z^),  err)),  11, 12, 13  i— *  ((0,  0),  err)]. 

In  the  same  way,  we  also  can  conclude  that  the  references  associated  with  the  occurrences 
fl,  f2  of  the  first  parameter  f  of  map  do  not  escape. 

4.6  Improving  Precision  of  Reference  Escapement 

We  present  a  method  of  improving  the  precision  of  reference  escape  information  that  is 
obtainable  through  the  reference  escape  analysis  by  using  position  information  about  inter¬ 
esting  references  in  a  list  structure.  We  describe  another  safe  and  computable  abstraction 
of  the  exact  reference  escape  semantics  that  gives  more  precise  information  about  refer¬ 
ence  escapement.  The  basic  improved  abstract  reference  escape  domain  is  constructed  by 
extending  the  basic  reference  escape  domain  to  include  additional  information  about  both 
spine  level  and  position.  We  safely  approximate  the  exact  reference  escape  semantics  by 
abstracting  the  reference  escape  semantic  subdomains  for  list  type  expressions,  and  by 
approximating  reference  escape  semantic  functions.  Abstraction  of  the  reference  escape  se¬ 
mantic  subdomains  for  list  type  expressions  is  done  by  representing  lists  as  finite  objects, 
i.e.  by  combining  the  reference  escape  pairs  of  all  its  elements  into  a  single  reference  escape 
pair. 

For  each  expression,  its  corresponding  value  in  the  improved  abstract  reference  escape 
domain  tells  us  if  an  interesting  reference  is  definitely  not  contained  in  the  value  of  the 
expression  (“non-reference-escape”),  or  if  an  interesting  reference  may  be  contained  at  some 
position  in  the  value  of  the  expression  (“possible  reference- escape  and  where”).  The  basic 
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<i,M> 


< 1 7  h , p  1) 

<1,  h,  p> 
(1,0,0) 


<1,0,  p-1) 
(1,0, p) 
(0,0,0) 


Figure  4.6:  The  Improved  Abstract  Basic  Reference  Escape  Domain 
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improved  abstract  reference  escape  domain,  Br,  for  some  fixed  p  is  shown  in  Figure  4.6. 
The  ordering  is  defined  as  follows: 

(0,0,0)  C  (1,0,  p)  C  (1,0, p  —  1)  C  ...C  (1,0,0)...  (l,h,p)Q  (l,h,p-  1)  C  ...C  (1,M) 

The  interpretation  of  the  elements  of  Br  is  dehned  as  follows: 

•  (1  ,j,k)  :  An  interesting  reference  may  be  contained  in  the  value  of  the  expression, 
and  if  y  >  1  then  it  is  a  reference  to  a  cons  cell  at  the  bottom  jth  spine  of  a  list  and  it 
may  occur  only  at  >  k  position.  (If  j  =  0  then  the  object  pointed  by  the  interesting 
reference  is  not  a  cons  cell.) 

•  (0,  0,  0)  :  No  interesting  reference  is  contained  in  the  value  of  the  expression. 

The  improved  abstract  reference  escape  semantic  domain  Dr  and  the  domain  Er  of 
improved  abstract  reference  escape  environments  are  dehned  as  follows: 

Dr  =  Dl  /*  Improved  abstract  reference  escape  semantic  domain  */ 

Er  —  Id  — »■  D,  /*  Domain  of  improved  reference  escape  environments  */ 

The  improved  abstract  reference  escape  subdomain  DJ.  for  expressions  of  type  t  is  dehned 


as  follows: 

jjint 

±sr 

=  Br  X  {err} 

improved  abstract  subdomain  for  integers 

rybool 
±J  r 

=  Br  X  {err} 

improved  abstract  subdomain  for  booleans 

£)T1->T2 

T 

=  Br  x  (D?  ->  D?) 

improved  abstract  subdomain  for  functions 

TAT  list 

=  d ; 

improved  abstract  subdomain  for  lists 

The  abstract  reference  escape  semantic  functions  are  dehned  as  follows: 

Rc  :  Con  — ►  Dr  /*  Improved  semantic  function  for  constants  */ 

Re  :  Exp  Er  —  Dr  /*  Improved  semantic  function  for  expressions  */ 

Rpr  :  Program  — >  Dr  /*  Improved  semantic  function  for  programs  */ 

The  improved  abstract  reference  escape  semantic  function  Rc  :  Con  — >  Dr  that  gives 
reference  escape  meaning  to  constants  is  given  in  Figure  4.7.  The  improved  abstract  value  of 
cons  takes  two  arguments,  and  returns  an  improved  reference  escape  pair  of  their  least  upper 
bound  by  updating  the  position  information  of  any  interesting  reference  in  the  resulting  list. 
The  improved  abstract  value  of  cars  returns  its  argument  according  to  the  position  of  any 
interesting  object.  cars  takes  a  list  with  s  spines  and  returns  the  element  that  was  in  the 
0th  position  and  has  (s  —  1)  spines.  Thus,  the  result  cannot  contain  an  interesting  reference 
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Rc\c\  =  ((0,  0,  0),  err),  c  £  {...,  — 1,  0, 1, true,  false} 

i?c[nilr  i!si]  =  _Lr  (  The  bottom  element  in  £E.) 


Eejcons] 


Eejcar3] 


Ecjcdr] 


-Rc[null] 


((0,  0,  0),  Xx.(x^,  Ay  .ipushf  a; ,  y))) 
where 

ipush(a;,2/)  =  if  (a;(i)(i)  =  1)  then 

<<M(1)(2)  U  J/(1)(2),0),X(2)  U  y(2)) 

elseif  ( a/( i ) ( i )  =  1)  then 

((1?  J/(i)(2)j  min(j/(1)(3)  +  l,p)),X(2)  U  2/(2)) 
else  <<0,  0,  0),  £(2)  U  2/(2)) 

((0,  0,  0),  Aa\icuts(a;)) 
where 

icuts(z)  =  if  (s  <  a(1)(2))  or  (z(1)(3)  >  0)  then  ((0,  0,  0),  z{2)) 
else  z 

((0,  0,  0),  Aa\rrest(a:)) 
where 

rrest(T)  =  ((^fi)(i),  ^i)(2),  max[z(1)(3)  -  1,  0]),  z{2)} 

«0,0,0),  Aa:.«0, 0,0),  err)) 


Figure  4.7:  Improved  Abstract  Reference  Escape  Semantic  Function 
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pointing  to  a  cons  cell  at  the  bottom  sth  spine  of  a  list  or  that  occurred  at  a  position  >  1  in 
the  original  list.  The  improved  abstract  value  of  cdr  also  updates  the  position  information 
appropriately.  Note  that  the  improved  abstract  reference  escape  semantic  function  Rc  for 
cons,  car  and  cdr  provides  more  precise  escape  information  than  the  abstract  reference 
escape  semantic  function  Rc. 

The  improved  abstract  reference  escape  semantic  functions  R,  and  Rpr  are  defined 
identically  to  Re  and  Rpr,  respectively  -  except  for  their  value  in  the  basic  domain. 

Let  u  and  v  be  values  of  an  expression  e  of  type  r  in  the  improved  abstract  reference 
escape  domain  Dr  and  the  exact  reference  escape  domain  l)r ,  respectively.  Let  n  be  the 
number  of  arguments  that  the  type  r  can  take  before  returning  a  value  of  primitive  type. 
We  say  that  the  improved  abstract  reference  escape  semantic  value  u  is  a  safe  approximation 
of  the  exact  reference  escape  semantic  value  v  iff 

(  U  P(l))  E  (NAPfc(tt,  St,  .  .  ..,«*))(!)(!) 

p  in  NAP k(v,ti,...,tk) 

and 

{MINp  in  NApfc^a,...,ifc)&p(ij=1  Position  of  p)  >  (NAP k(u,s%% .  .  • ,  .“a- ))(i)(;j) 
for  all  k  <  n  where  st  is  a  safe  approximation  for  C  for  all  i  <  k. 

Theorem  4.3  (Safety)  For  any  expression  e,  and  environments  envr  and  ehvr  such  that 
for  all  y,  ehrr[|/]  is  safe  for  envT\y\,  Re\e\ehvr  is  safe  (with  respect  to  reference  escape 
information )  for  Re\e\envr . 

Proof  :  We  can  prove  by  structural  induction  on  expression  e. 

I.  Base  Case: 

1.  e  =  c:  Re\c\envr  =  _Rc[c]  and  Re\c\envr  =  _Rc[c].  For  c£  {. . .  ,-1,0,1,. . .  ,  true, 
false,  nil,  null  }  ,  i?c[c]  =  _Rc[c]  and  thus  it  clearly  holds.  For  c  =  cons,  it  holds 
because  if  and  are  safe  f°r  Di  and  y2 ,  respectively,  then  ipush(a:(1p  x2)  is  also  safe  for 
a  list  consisting  of  yi  and  j/2.  It  holds  for  c  =  cars,  because  if  x  is  safe  for  y  then  icuts(r) 
is  safe  for  first(j/).  It  holds  for  c  =  cdrs,  because  if  x  is  safe  for  y  then  rrest(r)  is  safe  for 

secondly). 

2.  e  =  x\  Relxjeiivr  =  ehtyflx-]  and  Re\_x\envr  =  eriryfla-].  Since,  for  all  y,  ehrr[y]  is 
safe  for  envr\y\,  it  clearly  holds. 

II.  Structural  Induction  Step:  Assume  that  Re\e\envr  is  safe  for  Re\e\envr  for  expres¬ 
sions  such  as  Cq.  e±.  e2.  e,3  and  en.  (structural  induction  hypothesis)  Then,  we  show  that 
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RS 


SS 


IARS 


ARS  “information  content” 


Figure  4.8:  Relationship  among  Reference  Escape  Semantics 

Re\e\envr  is  safe  for  Re\e\env T  for  e\  +  eg,  if  e.j  then  e 2  else  eg,  e  —  ejeg,  lambda(a;).ei 
and  letrec  x\  =  ep, . .  .]xn  =  e„;  in  eg.  This  can  be  proved  in  an  exactly  same  way  as  the 
proof  of  safety  of  the  abstract  reference  escape  semantics.  □ 

Theorem  4.4  (Termination)  For  any  (finite)  program  pr  6  Program,  Rpr [pr]  is  com¬ 
putable,  i.e.  always  terminates  in  finite  number  of  steps. 

Proof  :  Every  functional  in  the  improved  reference  escape  domain  that  is  defined  via 
the  abstract  improved  extended  escape  semantic  functions  is  composed  of  the  operators 
such  as  the  least  upper  bound  operator  U,  ipush,  icuts,  and  rrest.  ipushs,  icuts  and  rrest 
are  monotonic  operators.  Since  the  composition  of  monotonic  functions  is  also  monotonic, 
every  functional  is  monotonic.  □ 

Theorem  4.5  (Precision  Improvement)  The  abstract  reference  escape  semantics  is  equiv¬ 
alent  (with  respect  to  their  reference  escapement  information  content)  to  the  improved  ab¬ 
stract  reference  escape  semantics  with  p  =  0.  Thus,  the  improved  abstract  reference  escape 
semantics  with  some  p  >  0  provides  more  precise  escape  information  than  the  abstract 
reference  escape  semantics. 

Proof  :  This  can  be  proved  in  the  similar  way  to  the  proof  of  Theorem  2.5.  □ 

The  relationship  among  the  standard  semantics  (SS),  the  non-standard  exact  reference 
escape  semantics  (RS),  the  abstract  reference  escape  semantics  (ARS)  and  the  improved 
abstract  reference  escape  semantics  (IARS)  is  shown  in  Figure  4.8. 
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Improved  Global  Reference  Escape  Test 

Given  a  function  /  x\  a;  2  . . .  xn  =  bodyf  of  arity  n,  the  position  (i.  y)  of  an  interesting 
reference  of  a  parameter,  and  an  improved  abstract  reference  escape  semantic  environment 
envr  mapping  /  to  an  element  of  Dr ,  the  improved  global  reference  escape  test  function 
GJrefescape?  which  determines  whether  the  reference  associated  with  the  jth  occurrence  of 
the  ith  parameter  of  /  could  escape  /  globally  is  defined  as  follows: 

GJrefescape?(/,  i,j,  ehvr)  = 

(■ Relf  X1  ...  .Cjo(j)  ...  Xn  ...  xao(n)  1  envr[f  ]',xy  2/ii])(i)(i) 

where  f  is  the  auxiliary  function  for  /, 

/'  =  Relfjenvr, 

yij  =  ((1,  Si,  0),  WTi),  /*  The  jth  occurrences  of  ith  parameter  is  interesting  */ 

Si  is  the  number  of  spines  of  the  ith  parameter  of  /  (if  it  is  a  list  type,  otherwise  s.t  is  0), 
for  all  k  <  o(i )  and  k  7^  j, 

yik  =  ((0,  0,  0),  WTi),  /*  Other  occurrences  of  ith  parameter  are  not  interesting  */ 
for  all  1  <  m  <  o(l)  and  l  7^  i. 

yirn  =  ((0,  0,  0),  I'Eri),  /*  Occurrences  of  other  parameters  are  not  interesting  */ 

and  T{  is  the  type  of  the  ith  parameter  of  /.  The  result  of  the  global  improved  reference 
escape  test  function  is  interpreted  as  follows: 

•  If  GJrefescape?(/,  i,j,  envr)  =  0  then  we  can  conclude  that  the  reference  associated 
with  the  jth  occurrence  of  the  ith  argument  does  not  escape  the  function  call  to  /  in 
any  possible  application  of  /  to  n  arguments. 

•  If  G _irefescape?( /,  1.  j.  ehz y)  =  1  then  the  reference  associated  with  the  jth  occurrence 
of  the  ith  argument  could  escape  the  function  call  to  /  in  some  possible  application  of 
f  to  n  arguments. 

Improved  Local  Reference  Escape  Test 

Given  a  function  f  xi  x 2  ...  xn  =  bodyj  of  arity  n  in  a  particular  function  application 
f  e  1  ...  en,  the  position  ( i,j )  of  an  interesting  reference  of  a  parameter,  and  an  improved 
abstract  reference  escape  semantic  environment  envr  mapping  /  and  the  free  identifiers 
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within  e\  through  en  to  elements  of  Dr ,  the  improved  global  reference  escape  test  function 
LJrefescape?  which  determines  whether  the  reference  associated  with  the  jth  occurrence  of 
the  ith  parameter  of  /  could  escape  /  locally  is  defined  as  follows: 

LJrefescape?(/,  i,  j,  el5 .  ,.,en,envr)  = 

1  ■  •  •  •  •  •  %n  •  ■  •  ^rio(ri)!  CTT'Cy  [,/  1  *  1  r  ^2j])(l)(l) 

where  f  is  the  auxiliary  function  for  /, 

/'  =  Re[f'\envr , 

Vij  =  <<1,  0),  (JRel[es]]efi^)(2)), 

Si  is  the  number  of  spines  of  the  ith  parameter  of  /  (if  it  is  a  hst  type,  otherwise  Si  is  0), 
for  all  k  <  o(i)  and  k  ^  j , 

Vik  =  ((0,0,0).?(^e[ei]e7it?r)(2))5 

for  all  1  <  m  <  o(l)  and  l  7^  i, 

Vim  =  ((0,  0,  0),  (-Re[e/]efsuf  )p))- 

The  result  of  the  local  improved  reference  escape  test  function  is  interpreted  as  follows: 

•  If  LJrefescape?  (/,  i,j,  , . . ,  en,  envr)  =  0  then  we  can  conclude  that  the  reference 
associated  with  the  jth  occurrence  of  the  ith  argument  does  not  escape  /  locally  in 
(/  ei  . . .  en). 

•  If  LJrefescape? ( /,  i,  j,  tj, . . . .  cn.  envr  )  =  1  then  it  means  that  the  reference  associated 

with  the  jth  occurrence  of  the  ith  argument  could  escape  /  locally  in  (/  . .  en). 

4.7  Complexity  of  Reference  Escape  Analysis 

The  abstract  interpretation  framework  for  the  reference  escape  analysis  that  deals  with 
higher-order  functional  languages  with  non-flat  domains  is  very  similar  to  the  framework 
for  strictness  analysis  for  higher-order  functional  languages  with  non-flat  domains.  Both 
analyses  use  a  ^-element  domain  where  k  is  fixed  and  greater  than  2  as  their  basic  abstract 
domains,  respectively.  Like  any  other  analysis  based  on  abstract  interpretation,  the  major 
complexity  of  our  analysis  comes  from  finding  the  fixpoints  of  recursive  functions  in  the 
abstract  semantic  domains.  In  our  analysis,  the  reference  escape  testing  is  performed  on 
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each  reference  associated  with  each  occurrence  of  a  parameter  of  a  function  separately  using 
its  auxiliary  function.  However,  since  the  auxiliary  function  for  a  function  is  never  recursive 
even  if  the  original  function  is  a  recursive  function,  the  process  of  finding  a  fixpoint  is  needed 
only  for  an  original  function,  but  is  never  needed  for  its  auxiliary  function.  Thus,  the  order 
of  time  complexity  of  reference  escape  analysis  is  the  same  as  that  of  strictness  analysis  for 
higher-order  languages  with  non-flat  domains,  which  is  exponential. 
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Chapter  5 


Order-of-Demand  Analysis 


In  lazy  evaluation,  arguments  to  a  function  are  not  evaluated  unless  and  until  their  values  are 
demanded,  and  are  evaluated  only  once  upon  the  first  demand.  Their  values  are  then  saved 
to  be  used  for  subsequent  demands,  thus  avoiding  reevaluation.  Exact  information  about 
the  strictness  of  arguments,  the  order  of  evaluation  among  arguments,  and  the  evaluation 
status  of  arguments  when  demanded  is  generally  unknown  at  compile-time.  If  inferred 
at  compile-time,  such  information  can  be  useful  for  a  number  of  optimizations  for  lazy 
evaluation. 

In  this  chapter,  we  present  a  method  for  statically  inferring  a  range  of  information 
including  strictness,  evaluation-order,  and  evaluation-status  information  in  a  higher-order, 
monomorphic,  non-strict  functional  language  with  lazy  evaluation.  This  method  is  based 
on  a  compile-time  analysis  called  order-of-demand  analysis  which  provides  safe  information 
about  the  order  in  which  the  values  of  bound  variables  are  demanded.  First,  we  introduce  a 
non-standard  denotational  semantics  called  before  semantics  that  describes  the  actual  order- 
of-demand  behavior,  but  is  incomputable  at  compile-time.  A  method  of  approximating  the 
exact  before  semantics  which  is  safe  with  respect  to  the  exact  before  semantics  and  is 
computable  at  compile-time  is  then  presented.  Based  on  this  abstract  before  semantics, 
we  describe  algorithms  which  determine  order-of-demand  information  and  the  complexity 
of  the  order-of-demand  analysis.  Finally,  extensions  of  the  order-of-demand  analysis  to 
a  parallel  lazy  evaluation  model,  to  an  optimized  lazy  evaluation  model  using  strictness 
information,  and  to  non-flat  domains  are  discussed. 
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5.1  Order  of  Demand  under  Lazy  Evaluation 


We  present  a  method  for  detecting  at  compile-time  a  range  of  information  including  strict¬ 
ness,  evaluation-order,  and  evaluation-status  information  in  a  higher-order  functional  lan¬ 
guage  being  implemented  using  lazy  evaluation.  The  range  of  information  can  be  reformu¬ 
lated  in  terms  of  information  on  order  of  demand  as  follows: 

•  Evaluation  Status:  Given  an  occurrence  x t  of  a  variable  x  in  the  body  of  a  function 
/,  for  each  possible  execution  of  the  body  of  / 

—  If  there  exists  another  occurrence  Xj  of  x  such  that  xj  is  demanded  before  xt 
(may  be  several  xf  s  in  different  paths),  then  we  know  that  x  must  have  been 
evaluated  by  the  time  x, ;  is  encountered. 

—  If  there  exists  no  occurrence  Xj  of  x  such  that  x  ■■  is  demanded  before  x t .  then  we 
know  that  x  must  have  not  been  evaluated  by  the  time  xt  is  encountered. 

•  Parameter  Evaluation  Order:  Given  two  parameters  x  and  y  of  a  function  /,  if  for 
every  occurrence  yt  of  y  in  the  body  of  /  there  exists  an  occurrence  xj  of  x  that  is 
demanded  before  yt.  then  we  can  conclude  that  x  will  always  be  evaluated  before  y. 

•  Strictness:  Given  a  parameter  a:  of  a  function  /,  and  an  imaginary  variable  $  which 
is  demanded  just  after  the  call  to  /  is  evaluated,  if  for  each  possible  (terminating) 
execution  of  the  body  of  /  some  occurrence  xt  of  x  was  demanded  before  $,  then  /  is 
strict  with  respect  to  x. 

Consider,  for  example,  the  following  function: 

f  w  x  y  z  =  if  w=0  then  z+x  elseif  y=0  then  z+x 
else  (z+y)  +  f  (w-1)  x  (y— 1 )  z 

We  assume  that  the  primitive  functions  such  as  +,  =  evaluate  their  arguments  in 

to-right  order.  For  convenience,  we  represent  each  occurrence  of  a  f ’s  bound  variable 
distinct  variable  as  follows: 

=  if  wl=0  then  zl+xl  elseif  yl=0  then  z2+x2 
else  (z3+y2)  +  f  (w2-l)  x3  (y3-l)  z4 

Our  order-of-demand  analysis  would  allow  us  to  determine  the  following  properties  of  the 
function  f  at  compile  time: 


left- 
as  a 
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•  Evaluation  Status :  When  the  value  of  y  is  demanded  via  y2  and  y3,  respectively,  y 
has  already  been  evaluated.  But,  when  it  is  demanded  via  yl,  y  has  not  yet  been 
evaluated  at  the  point. 

•  Parameter  Evaluation  Order:  The  parameters  to  f  are  evaluated  in  the  order  w,  z  and 

x. 

•  Strictness :  f  is  strict  in  w,  x  and  z,  but  is  not  strict  in  y. 

The  method  is  based  on  a  compile-time  analysis  called  order-of-demand  analysis  which 
provides  safe  information  about  the  order  in  which  the  values  of  variables  are  demanded. 
Rather  than  try  to  determine  the  relative  order-of-demand  between  all  possible  pairs  of 
occurrences,  it  turns  out  to  be  useful  and  more  efficient  to  define  an  order-of-demand  rela¬ 
tion  between  sets  of  occurrences.  We  define  a  relation  between  two  sets  of  occurrences  of 
parameters  of  a  function  which  specifies  the  order-of-demand  property  between  them. 

Definition  5.1  Given  two  non-empty  disjoint  sets  X  and  Y  of  labeled  occurrences  of  vari¬ 
ables  of  a  function  and  an  expression  e,  we  define  an  order-of-demand  relation  between  X 
and  Y  during  evaluation  of  an  expression  e  (which  contain  the  occurrences)  as  follows: 

•  Y  -<  X,  pronounced  Y  before  X ,  if  for  each  occurrence  x  £  X.  either  there  exists 
an  occurrence  y  £  Y  that  is  demanded  before  x  or  x  is  not  demanded  during  the 
evaluation  of  e. 

•  If  Y  -<  X  holds  for  any  possible  application  of  /  to  n  arguments  then  we  say  that 
Y  -<  X  globally.  If  Y  -<  X  holds  for  a  function  application  of  /  to  some  particular  n 
arguments  then  we  say  that  Y  -*<  X  locally. 

For  example,  some  properties  of  -<  among  occurrences  of  variables  in  f  given  above  are: 

•  {  yl>y3  }  ^  {  y2  },  {  yl  ,y2  }  ^  {  y3  },  and  {  y2,y3  }  /  {  yl  }. 

•  {  wl,w2  }  -<  {  zl,z2,z3,z4  }  and  {  zi,z2,z3,z4  }  -<  {  xl,x2,x3  }. 

•  {  wl,w2  }-<:{$},{  xl,x2,x3  }-<:{$},{  zl,z2,z3,z4  }-<:{$},  and  {  yl,y2,y3 
}  /  {  Si  }  where  $  denotes  an  occurrence  of  an  imaginary  variable  that  is  demanded 
after  (f  w  x  y  z)  is  evaluated. 

The  order-of-demand  analysis  described  here  answers  the  following  question:  Given  a 
function  and  two  sets  X  and  Y  of  occurrences  of  the  function’s  bound  variables,  which 
of  the  following  relations  holds,  if  any  :  Y  -<  X  or  X  -<  Y.  We  will  develop  a  method 
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for  a  liiglier-order,  monomorphic,  non-strict  functional  language  to  answer  the  following 
questions  at  compile-time: 

•  Given  a  function,  what  is  the  order  of  demand  between  the  parameters  or  locally 
defined  objects  within  the  function,  globally? 

•  Given  a  function  in  a  particular  application,  what  is  the  order  of  demand  between  the 
parameters  or  locally  defined  objects  locally? 

Function  Transformation 

The  first  step  in  the  order-of-demand  analysis  is  to  differentiate  between  the  (textual) 
occurrences  of  each  bound  variable  in  a  function  definition.  Although  this  seems  strange 
at  first,  it  quickly  becomes  apparent  that  each  occurrence  of  a  variable  denotes  a  different 
instance  in  which  the  value  of  the  variable  could  be  demanded.  Roughly  speaking,  the 
order-of-demand  analysis  that  we  describe  can  determine  the  relative  order  in  which  the 
values  of  various  occurrences  of  a  variable,  or  several  variables,  are  demanded.  In  order  to 
make  each  occurrence  of  a  bound  variable  distinct,  we  introduce  an  auxiliary  function  f  for 
each  function  /  x  +. . .  x  n  =  bodyj  based  on  the  same  transformation  described  in  Chapter  4. 
For  example,  the  auxiliary  function  f  ’  of  f  given  above  is  defined  as  follows: 

f’  wl  w2  xl  x2  x3  yl  y2  y3  zl  z2  z3  z4 

=  if  wl=0  then  zl+xl  elseif  yl=0  then  z2+x2 
else  (z3+y2)  +  f  (w2-l)  x3  (y3-l)  z4 


5.2  Before  Analysis 

In  this  section,  we  present  an  order-of-demand  analysis  called  before  analysis  which  provides 
safe  compile-time  information  about  before  demand  based  on  an  abstract  interpretation 
technique.  We  assume  that  the  underlying  evaluation  model  for  the  higher-order  non-strict 
functional  language  is  sequential  lazy  evaluation.  That  is,  the  evaluation  of  arguments  of 
strict  primitive  functions  are  predefined  in  a  sequential  order  (either  left-to-right  or  right- 
to-left)  at  compile-time  and  no  optimization  using  strictness  information  is  applied.  The 
cases  in  which  the  underlying  evaluation  model  is  a  parallel  lazy  evaluation  model  where 
arguments  of  strict  primitive  functions  may  be  evaluated  in  parallel,  and  an  optimized 
lazy  evaluation  using  strictness  information  in  which  all  strict  arguments  of  a  function  are 
evaluated  at  the  time  of  a  call  to  the  function  either  sequentially  or  in  parallel  will  be 
discussed  in  section  5.5. 
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5.2.1  Exact  Before  Semantics 


We  introduce  an  exact,  but  incomputable,  non-standard  denotational  semantics  called  be¬ 
fore  semantics,  which  exactly  describes  the  actual  -<  relation  between  any  two  occurrences 
of  a  parameter  of  a  function  in  a  program.  Since  the  exact  before  relation  during  a  pro¬ 
gram’s  execution  depends  on  the  standard  values  themselves  (e.g.  the  standard  value  of  the 
predicate  part  of  a  conditional  will  determines  which  alternative  will  be  taken),  any  exact 
before  semantics  needs  to  contain  the  standard  meanings  of  expressions  as  well  as  before 
information. 

Two  sets  of  occurrences  of  parameters  of  a  function  will  be  analyzed  separately  to 
determine  the  function’s  before  behavior.  We  say  that  two  particular  sets  of  occurrences  of 
parameters  of  a  function  interesting  sets  if  we  are  trying  to  determine  the  before  relation 
between  them.  Thus,  our  before  semantics  is  defined  in  terms  of  two  interesting  sets  X 
and  Y  of  occurrences  of  variables  inside  a  function.  The  exact  before  semantics  determines, 
given  an  expression  e  and  two  interesting  sets  X  and  Y  of  occurrences  of  variables  that  are 
contained  in  e,  whether  the  relation  X  -<  Y  holds  as  a  result  of  the  evaluation  of  e. 

Representing  Before  Information 

For  each  expression,  its  corresponding  value  in  the  before  semantic  domain  should  indicate 
whether  the  relation  Y  before  X  holds  during  evaluation  or  not.  Under  the  non-standard 
before  semantics,  we  represent  the  meaning  of  an  expression  e,  with  respect  to  interesting 
sets  X  and  Y,  as  a  pair  in  the  non-standard  before  semantic  domain  Dt,  called  a  before 
pair, 

1.  whose  first  element  denotes  the  before  information  during  evaluation  of  the  expression, 
and 

2.  whose  second  element  denotes  the  functional  behavior  of  the  expression  e  when  it  is 
applied  to  another  expression. 

The  first  component  of  the  pair  is  an  element  of  a  domain  called  a  basic  before  domain ,  If , 
which  is  a  three-element  domain  of  0,  1  and  2  ordered  by  0  C  1  C  2  as  shown  in  Figure  5.1. 
The  elements  in  Bt  are  interpreted  as  follows: 

•  2  :  For  each  occurrence  x  6  X,  x  is  demanded  and  no  occurrence  y  6  Y  is  demanded 
before  x  during  the  evaluation  of  e. 
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Figure  5.1:  The  Basic  Before  Domain 

•  1:  For  each  occurrence  x  £  X,  neither  x  nor  y  £  Y  is  demanded  during  the  evaluation 
of  e. 

•  0  :  For  each  occurrence  x  £  X ,  either  x  is  demanded  and  an  occurrence  y  £  Y  is 
demanded  before  x  or  x  is  not  demanded  and  an  occurrence  y  £  Y  is  demanded  during 
the  evaluation  of  e. 

The  second  component  of  the  pair  is  a  function  over  Dt.  whose  meaning  is  the  functional 
behavior  of  the  expression  e  when  it  is  applied  to  another  expression.  For  expressions  which 
have  no  higher-order  behavior,  err,  a  function  that  can  never  be  applied,  is  used. 

Before  Semantic  Domains 

The  before  semantic  domain  Dt  and  the  before  environment  Et  are  defined  as  follows: 

Dt  =  /*  Before  semantic  domain  */ 

Et  =  Id  —  Dt  /*  Domain  of  before  environments  */ 

The  before  domain  Dt  is  a  sum  domain  consisting  of  each  subdomain  for  each  type.  The 
before  subdomain  DJ  for  expressions  of  type  r  is  defined  as  follows: 

D\nt  =  B{  X  {err}  subdomain  for  integers 

jjbool  —  Bt  x  {err}  subdomain  for  booleans 

=  5;  X  {Dl1  — ►  D J2)  subdomain  for  functions  of  type  T\  — ►  r2 

Before  Semantic  Functions 

We  introduce  the  non-standard  before  semantic  functions,  Tc,  7, ,  and  Tpr,  which  give  non¬ 
standard  before  meaning  to  constants,  expressions  and  programs,  respectively. 
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Tc  :  Con  —  Dt  /*  Before  semantic  function  for  constants  */ 

Te  :  Exp  —?  Et  —?  Dt  /*  Before  semantic  function  for  expressions  * / 

Tpr  :  Program  —  Dt  /*  Before  semantic  function  for  programs  */ 

We  define  a  binary  operator  t>  which  reflects  the  notion  of  sequential  evaluation  of  two 
expressions  as  follows: 

>  :  Bt  -+  Bt  -+  Bt 

JJ  >  V  =f  if  (U  =  1)  then  V  else  U 

Consider  an  expression  e  which  consists  of  two  subexpressions  ey  and  e2  such  that  the 
evaluation  of  .ej  is  followed  by  the  evaluation  of  e^-  If  the  value  of  ey  in  Bt  with  respect 
to  X  and  Y  is  0  then,  during  the  evaluation  of  ey,  any  demand  to  an  occurrence  x  £  X  is 
preceded  by  a  demand  to  an  occurrence  y  £  Y  and,  furthermore,  at  least  one  occurrence 
in  Y  is  demanded.  Thus,  regardless  of  the  value  of  e2  in  Bt,  the  before  information  of  e  is 
always  0. 

If  the  value  of  ey  in  Bt  with  respect  to  X  and  Y  is  2,  then,  during  the  evaluation  of  ty , 
any  demand  to  an  occurrence  y  £  Y  is  preceded  by  a  demand  to  an  occurrence  x  £  X  and, 
furthermore,  at  least  one  occurrence  in  X  is  demanded.  Thus,  regardless  of  the  value  of  e2 
in  Bt ,  the  before  information  of  e  is  always  2. 

If  the  value  of  ty  in  Bt  with  respect  to  X  and  Y  is  1,  then  no  occurrence  o  £  X  U  V 
is  demanded  during  evaluation  of  e-y.  Therefore,  the  value  of  e  in  If  depends  only  on,  and 
is  equal  to,  the  value  of  e->  in  Bt .  Thus  the  t>  operator  reflects  precisely  the  notion  of 
sequential  evaluation  of  two  expressions. 

The  semantic  equations  for  the  before  semantic  functions  are  expressed  in  Figure  5.2. 
Oracle  is  used  to  resolve  the  exact  behavior  of  the  conditional  primitive  function,  deter¬ 
mining  which  branch  would  be  evaluated  at  run-time.  Since  this  must  rely  on  the  standard 
value  of  a  predicate,  the  exact  before  semantics  is  not  computable  at  compile-time.  envt  is 
any  exact  before  environment  in  Et,  and  nullenvt  is  a  before  environment  that  maps  every 
identifier  to  the  least  element  of  its  before  semantic  domain. 

5.2.2  Abstract  Before  Semantics 

Since  the  information  that  the  before  semantics  provides  is  uncomputable  at  compile  time, 
it  is  not  suitable  as  a  basis  for  compile-time  analysis.  For  use  in  a  compiler,  we  need  a 
suitable  before  semantics  that  will  guarantee  termination  and  yet  still  provide  a  useful  and 
safe  approximation  to  the  exact  before  semantics.  In  this  section,  we  present  an  abstract 
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Tc  [c]  =  (1,  err),  c  £  1,  0, 1, true,  false} 


Telc}envt  =  Tc[c ] 

Te{xjenvt  =  envt{xj 

Te[ei  +  e2 Jenvt  =  let  l  =  Te\e-[\envt  /*  same  for  e\  —  e2  and  e\  =  e2  * / 

r  =  Te[e2]erint 

in  </(i)  >  r^err) 

Te[if  ei  then  e2  else  e^\env-t  =  let  p  =  Te\ei\envt 

c  =  Tele2Jenvt 
a  =  Te[e3]erant 

in  if  Oracle(ei)  then  t>c^),C(2)) 
else  (p(1)  >  «(x),  «(2)) 

re[eie2]erint  =  let  /  =  T^e^envt 

ap  =  -2j<  nrt) 

in  (/(1)  >  ap^,ap{2)) 

Te [  1  amb d&(x).ejenvt  =  (1,  \y.Te{e\enVi[x  i-+  y]) 

Te[letrec  zi  =  ei; . . . ;  xn  =  e„;  in  eJeriUj  =  Te[e]ennj 

where  env't  =  eriUt[a;i  Te[ej]ennj, . .  ,,xn  Te[en]ennj] 

^[pr]  =  Te[pr]rari//ennj; 

Figure  5.2:  Before  Semantic  Functions 
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Figure  5.3:  The  Abstract  Basic  Before  Domain 

interpretation  of  the  exact  before  semantics  that  allows  a  safe  approximation  of  the  exact 
before  behavior  to  be  found  at  compile-time. 

Abstract  Before  Semantic  Domains 

For  each  expression,  its  corresponding  value  in  the  abstract  before  semantic  domain  indicates 
whether  the  relation  of  Y  before  A  holds  definitely  during  the  evaluation  of  the  expression 
(“before”),  and  whether  the  relation  of  Y  before  X  may  hold  during  the  evaluation  of  the 
expression  (“maybe  before”).  As  an  abstraction  of  Bt,  we  define  an  abstract  basic  before 
domain  Bt  as  a  three-element  domain  of  0,  1  and  2  ordered  by  0  C  1  C  2  that  is  similar  to 
the  basic  before  domain  Bt  as  shown  in  Figure  5.3.  But,  the  interpretation  of  elements 
in  Bt  is  defined  differently  from  that  of  Bt  as  follows: 

•  2  :  For  each  occurrence  x  £  A',  either  x  is  demanded  and  an  occurrence  y  £  V  might 
(or  might  not)  be  demanded  before  x.  or  x  is  not  demanded  and  an  occurrence  y  £  Y 
might  (or  might  not)  be  demanded  during  evaluation  of  e.  (In  other  words,  this  value 
denotes  the  absence  of  knowledge  about  the  relative  order  of  demands.) 

•  1  :  For  each  occurrence  x  £  A .  either  x  is  demanded  and  an  occurrence  y  £  Y  is 
demanded  before  x ,  or  x  is  not  demanded  and  an  occurrence  y  £  Y  might  (or  might 
not)  be  demanded  during  evaluation  of  e. 

•  0  :  For  each  occurrence  x  £  A,  either  x  is  demanded  and  an  occurrence  y  £  Y  is 
demanded  before  x ,  or  x  is  not  demanded  and  an  occurrence  y  £  Y  is  demanded 
during  the  evaluation  of  e. 

Note  that  the  value  in  Bt  of  an  expression  e  consisting  only  of  the  variable  x  is  2  if  x  £  A| 
0  if  x  £  Y,  1  if  ar  ^  (A  U  Y).  The  abstract  before  semantic  domain  Dt,  the  domain  Et  of 
abstract  before  environments  are  defined  as  follows: 
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Di  =  '^DJ  /*  Abstract  before  semantic  domain  */ 

Et  =  Id  — >  Df  /*  Domain  of  abstract  before  environments  */ 

The  before  subdomain  D J  for  expressions  of  type  r  is  defined  as  follows: 

D"lt  =  Jit  X  {err}  abstract  subdomain  for  integers 

—  Bt  x  {err}  abstract  subdomain  for  booleans 

D(1^T2  =  Bf  X  (Uf1  — ►  Dt2)  abstract  subdomain  for  functions  of  type  7"i  — >  r 2 

Abstract  Before  Semantic  Functions 

The  abstract  before  semantic  functions  are  defined  as  follows: 

Tc  :  C'on  —  Dt  /*  Abstract  before  semantic  function  for  constants  */ 

Te  :  Exp  Et  —  Dt  /*  Abstract  before  semantic  function  for  expressions  * / 

Tpt  :  Program  — >  Dj  /*  Abstract  before  semantic  function  for  programs  */ 

The  abstract  before  semantic  functions  are  given  in  Figure  5.4.  envt  is  any  abstract  before 
environment  in  Et,  and  nuUenvt  is  an  abstract  before  environment  that  maps  every  identifier 
to  the  least  element  of  its  abstract  before  semantic  domain. 

Safety  and  Termination 

We  introduce  the  notion  of  safety  which  relates  the  exact  before  semantics  to  the  abstract 
before  semantics.  Let  u  and  v  be  values  of  an  expression  e  of  type  r  or  r  list  in  Dt  and  I)/ . 
respectively.  Let  n  be  the  number  of  arguments  that  the  type  r  can  take  before  returning 
a  value  of  primitive  type.  We  say  that  u  is  a  safe  approximation  (with  respect  to  before 
information)  of  v  iff 

(NAP/Tu,  «i,  • . «*»(!)  E  (NAPa(w;  h,  ■  •  •Da))(i)- 

for  all  k  <  n  where  Sj  is  a  safe  approximation  of  f4-  for  all  i  <  k. 

Theorem  5.1  (Safety)  For  any  expression  e,  and  environments  envt  and  ehvt  such  that 
for  all  y,  ehutl'j/]  is  safe  for  Te[e]ehnt  is  safe  (with  respect  to  before  information) 

for  Te\e\envt.  Thus,  the  before  information  obtained  by  the  exact  before  semantics  implies 
the  before  information  obtained  by  the  abstract  before  semantics. 

Proof  :  We  can  prove  by  structural  induction  on  expression  e. 

I.  Base  Case: 
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Te[c]  =  (1  ,err)  c  G  {..., —1,  0, 1, true,  false} 

fe{cjenvt  =  Tc[c] 
fe{x}envt  =  envt{xj 

Te[ei  +  e2 Jenvt  =  let  l  =  Te\e-[\envt  /*  same  for  ej  —  e2  and  ej  =  e2  */ 

r  =  Tele2}envt 

in  (/(!)  >  f(1),err) 

Te[if  ei  then  e2  else  eg] envt  =  let  p  =  7f  [<  1 hrt 

c  =  Tele2Jenvt 
a  =  Te[e3]erirt 

ill  (p(1)  >  C(1),C(2))  U<P(i)  >«(i),«(2)) 

/,  1'  i<?2 1'  nvt  =  let  /  =  fe[ei]enrt) 

<>P  =  /(2)(re[e2]enrt) 
in  (/(!)  >  dp(1),dp(2)) 

Te[lambda(r).e]eriri  =  (1,A y .Te\e\envt[x  ^  y]) 

Te[letrec  x\  =  e^; . . . ;  xn  =  eK;  in  ejehrt  =  Te[e]ehrj 

where  env't  =  re[ei]erit4, . . . ,  xn  i— >  Te[en]erirj] 

Tpr{pr\  =  Telpr}nullenvt 

Figure  5.4:  Abstract  Before  Semantic  Functions 
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1.  e  =  c:  felc}envt  -  Tc[c]  and  Te{cjenvt  =  Tc |c].  For  c  G  {. . .  ,-1,0,1,.  .  .  ,  true, 
false,  nil,  null  }  ,  Tcjc]  =  Tc[c]  and  then  it  clearly  holds. 

2.  e  =  x:  Feja’Jehut  =  ehrt[a-]  and  Te\x\envt  =  enryja-].  Since,  for  all  y ,  ehutjt/]  is  safe 
for  envt [?/] .  it  clearly  holds. 

II.  Structural  Induction  Step:  Assume  that  Te\e\envt  is  safe  for  Te\e\envt  for  expressions 
such  as  Co,  ('a  and  en.  ( structural  induction  hypothesis) 

1.  e  =  ei  +  e2:  Te\ei-\-e2\ehvt=  (l^  \>  f^,  err)  where  /  =  Te\ei\ehvt  and  r  =  T£le2Jenvt. 

Telei  +  e2 Jenvt  =  err)  where  /  =  Te\ei\envt  and  r  =  Tele2Jenvt.  By  the  structural 

induction  hypothesis,  /  and  f  are  safe  for  /  and  r,  respectively.  Thus,  it  holds.  Similarly,  it 
holds  for  ei  —  e2  and  ej  —  e2. 

2.  e  =  if  e\  then  e2  else  e3:  Te[if  e3  then  e2  else  e3Jehvt  =  {p(\)  \>  C(i),C(2))  LI 

(P( i)  l>  h(i),  C(2))  where  p  =  Te\ei\envt,  c  =  fe{e2Jenvt,  and  a  =  fe\e^\envt.  Te [if  e1  then 
e2  else  e3Jenvt  is  either  (p^  t>  c^,c^)  or  >  C(1),C(2))  where  p  =  Te[ei]ehrt,  c  = 

Te Plenty,  and  a  =  Tele3Jenvt  depending  on  the  standard  semantic  value  of  ei.  In  any 
case,  by  the  structural  induction  hypothesis  and  the  dehnition  of  t> ,  it  holds. 

3.  e  =  exe2:  Te[e1e2]ehut=  (/(1)  1>  a>(1),dp(2))  where  /  =  7,  [ejjf  hr,).  and  dp  = 
f(2)(Tele2Jehvt).  T^e^eri®^  (/(1)  >  ap(1),  ap(2))  where  /  =  7,  [cj  hr,),  and  ap  = 
f(2){Tele2Jenvt).  By  the  structural  induction  hypothesis,  /  and  dp  are  safe  for  /  and  ap, 
respectively.  Then,  by  the  definition  of  t>  and  safe,  it  holds. 

4.  e  =  lambda(a:).ei:  Te[lambda(a:).e]efiUt=  (1,  Ar/.T^feJehrf [a;  h- >  y]).  Te[lambda(a;).e] 
envt=  { 1 .  A(/.7,  |<  [<  nV([x  i— >  y\).  By  the  structural  induction  hypothesis,  Te[e]ehut[a:  i— >  y\ 
is  safe  for  T^JeJenryfa;  hh>  y\  and  thus  it  holds. 

5.  e  =  letrec  a’i  =  ej; . . xn  =  en;  in  eo:  Te[letrec  xi  =  ... ;  an  =  e„;  in  eo]ent^= 

Te[eo]ehuj  where  env)—  envt[xi  hh>  T^je^e-hr^],  and  T^Jletrec  X\  —  e  j ; . . . :  a;n  =  e„;  in  eo] 
envt—  71e[eo]eriUj  where  env't=  envt[xi  7f[ei]enrt/].  Here,  env'  and  env'  are  recursively 
defined.  We  prove  that  ehrjjt/]  is  safe  for  env)  [it/]  for  all  y  by  fixpoint  induction  on  envi¬ 
ronments  env' . 

1.  Base  Case:  The  first  approximation  env of  env)  is  envt[xj  hh>  J_],  The  first  approx¬ 
imation  envj'0'  of  env)  is  envt[x j  i— >  _L],  Thus,  for  all  y,  ehrj[t/]  is  safe  for  erir)[|/]. 
Then,  by  the  structural  induction  hypothesis,  Te\eo\env).  is  safe  for  Te\eo\env). 

2.  Fixpoint  Induction  Step:  Assume  that,  for  some  fixed  k  >  0,  the  kth  approxima¬ 
tion  env^'lyj  is  safe  for  env^ [r/]  for  all  y.  (fixpoint  induction  hypothesis)  Then, 
The  ( k  +  l)th  approximation  env}k+1^=  envt[xi  i-+  Te\ei\env^ ],  and  env^k+1^  = 
envt[xi  i — *  Teleijenv^].  By  the  structural  induction  hypothesis,  Te\ei\env^  is  safe 
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Figure  5.5:  Relationship  among  Standard  and  Before  semantics 

for  Te\ei\env}k\  Thus,  envt^k+1^ [j/]  is  safe  for  envt^k+1\y\  for  all  y.  Then,  by  the 
structural  induction  hypothesis,  2fc[eo]efiv4  is  safe  for  Te\eo\env[. 

□ 

Theorem  5.2  (Termination)  For  any  (finite)  program  pr  £  Program,  1  pr [pr]  is  com¬ 
putable,  i.e.  it  always  terminates  infinite  number  of  steps. 

Proof  :  All  the  abstract  before  semantic  domains  are  finite,  and,  because  the  operator  > 
is  monotonic,  all  functions  over  before  semantics  domains  are  monotonic  functions.  Thus, 
the  hxpoints  can  be  computed  in  a  finite  number  of  steps,  and  the  interpretation  under  the 
abstract  before  semantics  is  guaranteed  to  terminate  for  all  programs.  □ 

The  relationship  among  the  standard  semantics  (SS),  the  non-standard  exact  before  se¬ 
mantics  (BS),  and  the  abstract  before  semantics  (ABS)  is  shown  in  Figure  5.5. 

5.2.3  Testing  for  Before  Demand 

Since  the  abstract  before  semantics  is  guaranteed  to  terminate,  the  abstract  before  semantics 
can  be  used  as  a  basis  to  infer  the  before  information  at  compile-time.  We  consider  two 
kinds  of  before  information  for  higher-order  functions:  global  and  local.  The  global  before 
information  of  a  function  /  defined  by  /  x%  . . .  x n  =  bodyj  holds  true  for  every  possible 
application  of  /  to  n  arguments,  and  is  determined  by  examining  only  at  the  body  of  /. 
The  local  before  information  is  computed  for  a  particular  application  of  /  and  depends 
upon  the  number  and  properties  of  the  arguments  in  the  application.  It  turns  out  that  the 
global  before  information  is  equivalent  to  the  local  before  information  in  case  of  first-order 
functions. 
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Global  Before  Test 


The  global  before  testing  of  a  function  /  is  performed  by  applying  the  abstract  before 
semantic  value  of  /  to  n  arguments  in  Dt  that  contain  the  least  before  information  possible. 
Thus,  any  before  information  obtained  from  the  application  arises  solely  from  properties  of 
/■ 

Definition  5.2  (Worst-case  Before  Function)  For  each  type  r  such  that  m  is  the  num¬ 
ber  of  arguments  that  a  function  of  type  r  can  take  before  returning  a  primitive  value,  we 
define  the  abstract  function  WT  that  corresponds  to  the  worst-case  (i.e.  least)  before  infor¬ 
mation. 

m 

A*i-(1,  Aai2.(l, . . . ,  Axm.(  | _ | £«(],)  j  err) . . .))  m>  1 

1  =  1 

err  m  =  0 

Given  a  function  /  defined  by  /  ...  xn  =  bodyj  of  type  /  :  T\  — >  . . .  — >  rn  — *  r,  two  sets 

X  and  Y  of  occurrences  of  the  formal  parameters  of  /,  and  an  abstract  before  semantic 
environment  envt  mapping  /  to  an  element  in  Dt,  the  global  analysis  function  G_before? 
determines  whether  the  before  relation  between  X  and  Y  holds  globally,  ft  is  defined  as 
follows: 

G_before?(/,  X ,  Y ,  ehvt )  = 

Telf  xn  ...  xlo{1)  ...xnl. .  .a;„0(„)]  ehvt[f  h->  ytj] 

where 

f  is  the  auxiliary  function  for  /,  /'  =  Te\f~\envt,  o(i )  is  the  number  of  occur¬ 
rences  of  Xi, 

for  each  Xij  G  X, 

Vij  =  (2,  JTr‘), 

for  each  G  Y, 

yn  =  (o  ,^Ti), 

and  for  each  $  X  U  Y, 

Xij  =  ( 1 ,  Wn ) . 

The  value  that  G_before?(/,  X,  Y,  envl)  returns  is  a  pair  (p,g)  interpreted  as  follows: 


l  f  '  r  d=  { 
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•  If  p  =  0  or  1,  then  we  can  conclude  that  Y  -<  X  in  any  possible  application  of  /  to  n 
arguments. 

•  Otherwise,  if  p  =  2  then  an  occurrence  in  Y  might  or  might  not  be  demanded  before 
the  first  demand  of  any  occurrence  in  X.  Thus,  in  this  case,  we  cannot  conclude  that 
Y  -<  X  in  all  possible  applications  of  /. 

If  the  result  in  the  standard  semantics  of  the  application  of  /  to  n  arguments  is  a  function  g, 
then  G -before?  will  only  give  us  the  order-of-demand  information  about  the  bound  variable 
occurrences  inside  the  body  of  /  during  the  execution  of  the  application  of  /.  We  might  also 
want  to  obtain  order-of-demand  information  about  the  bound  variable  occurrences  inside  / 
if  g  were  subsequently  applied  to  other  arguments.  This  extra  amount  of  order-of-demand 
information  is  obtained  by  applying  g  to  the  abstract  value  (l,VFTfl),  where  Tg  is  the  type 
of  the  argument  expected  by  the  result  of  /. 

For  example,  consider  a  function  defined  by 

fxyz=ifx=0  then  lambda(w) .z+y+w 
else  lambda(w) .z*y*w 

The  auxiliary  function  f  ’  derived  from  f  is 

f’  x  yl  y2  zl  z2  =  if  x  =  0  then  lambda(w) .zl+yl+wl 

else  lambda(w) .z2*y2*w2 

G -before? (f , {yl ,y2} , {zl ,z2})  would  return  <  l.g  >  indicating  that  neither  y  nor  z  is 
demanded  during  an  application  of  f  to  three  arguments.  If  the  result  of  the  application  of 
f  is  applied  to  a  fourth  argument,  the  information  that  z  would  always  be  demanded  before 
y  can  be  obtained  by  applying  g  to  the  abstract  value  (l,err). 

Local  Before  Test 

Given  a  function  /  defined  by  /  x\  . . .  xn  =  bodyj  of  type  /  :  iq  — ►  . . .  — ►  r„  — >  r  in  a  par¬ 
ticular  application  f  e i  ...  em,  two  sets  X  and  Y  of  occurrences  of  /’ s  formal  parameters, 
and  an  abstract  before  semantic  environment  ehvt  mapping  /  and  all  free  identifiers  within 
d  and  en  to  elements  of  Dt,  the  local  analysis  function  L_before?  determines  whether  the 
before  relation  between  X  and  Y  holds  locally  in  /  ei  . . .  em.  It  is  defined  as  follows: 

L _before?(/,  ei, . . . ,  em,X.  Y,  efivt)  = 

(Telf  $11  •••  $10.(1)  •  •  •  Xml  .  .  .  $mo(m)l ehvt[f  /',  Xij  $„])(!) 
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where 


f  is  the  auxihary  function  for  /,  /'  =  Te[f'\envt ,  o(i)  is  the  number  of  occur¬ 
rences  of  Xi, 

for  each  xtJ  G  A”, 

Vi]  =  (2,  (re[e8]efiut)(2)), 

for  each  xlJ  G  Y, 

Vij  =  (0,  (Te[e!]eriut)(2)), 

and  for  each  xl;i  $  X  U  Y, 

Vij  =  (1,  (#e[ei]eh%)(2)). 

Then, 

•  If  L_before?(  /,  ei, . . . ,  em,  X,  Y,  ehvt)  =  0  or  1  then  we  can  conclude  that  Y  -<  X  in 
the  evaluation  of  (/  e\  . .  ,em). 

•  Otherwise,  if  L_before?(/,  ej, . . . ,  ern .  X .  Y.  cnvt)  =  2  then  an  occurrence  in  Y  might  or 
might  not  be  demanded  before  an  occurrence  in  X.  Thus,  in  this  case,  we  are  unable 
to  conclude  that  Y  -<  X  during  the  evaluation  of  (/  e\  ...  em). 

5.3  Using  Before  Analysis 

Our  motivation  for  developing  the  order-of-demand  analysis  is  to  obtain  evaluation  status 
information.  As  we  describe  above,  evaluation  status  information  can  be  used  to  optimize 
lazy  evaluation  by  avoiding  run-time  checks  to  see  if  a  bound  variable  is  evaluated  or  not. 
Since  each  occurrence  of  a  bound  variable  corresponds  to  a  potential  demand  for  the  value 
of  the  variable,  order-of-demand  analysis  is  used  to  determine  which  occurrences  correspond 
to  demands  of  an  already  evaluated  variable. 

As  a  nice  side-effect,  order-of-demand  analysis  can  be  used  to  compute  (approximately, 
of  course)  the  relative  evaluation  orders  of  the  parameters  of  a  function,  and  the  strictness 
properties  of  a  function. 
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5.3.1  Computing  Status-of-Evaluation  Information 

Given  an  occurrence  x±j  of  a  bound  variable  X{,  if  we  can  determine  that  there  will  always 
be  some  other  occurrence  x ^  of  xt  demanded  before  x ,  j ,  then  no  run-time  test  of  the  status 
of  Xi  is  required  when  xl;-  is  demanded. 

We  can  determine  the  evaluation  status  of  z,-j  when  it  is  demanded  by  computing  the 
order  of  demand  information  between  x-tj  and  all  other  occurrences  of  x,L. 

Theorem  5.3  Let  f  be  a  function  defined  by  f  x i  . .  ,xn  =  bodyj  and  xn, . .  - ,  be  all 
the  occurrences  of  Xi  in  body f.  Then, 

1.  ( G_before?(  /,  {z;j},  {xn, . . . ,  xio^}  —  { Xij},ehvt ))p)  —  0  or  1  =>  whenever  .r*_;  is 
demanded,  X{  will  have  already  been  evaluated  and  thus  the  demand  can  be  satisfied 
by  retrieving  the  saved  value,  for  any  possible  application  of  f . 

2.  (G_before?(/,  {zji, .  ■  ■  ■ ,  xio(i)}  ~  ent?t))(i)  —  0  or  1  =$■  the  demand  on  x^j 

the  first  demand  of  any  occurrence  of  x^,  and  thus  will  always  be  the  occurrence  (if 
any)  causing  the  evaluation  of  a^. 

Proof  :  If  (G_before?(/,  {aijj},  {a:,!, . . a:^)}  —  {$ij})re)m  =  0  or  1  then  some  occurrence 
of  Xi  other  than  Xij  is  always  demanded  before  the  occurrence  X{j  is  ever  demanded  first. 
This  means  that  whenever  x.l;i  is  ever  demanded,  xt  has  been  already  evaluated. 

If  ( G_before?( /,  {xn, . . . ,  xio^}  —  {xij},  {aq-j},  ehvt))^  =  0  or  1  then  before  any  occur¬ 
rence  Xik  of  Xi,  k  j,  is  demanded  x±j  must  be  demanded.  Thus,  whenever  Xjj-  is  ever 
demanded  it  is  the  first  demand  of  Xi  which  causes  actual  evaluation  of  Xi,  and  thus  x^  has 
an  unevaluated  status.  □ 

A  similar  theorem  can  be  stated  about  the  use  of  the  local  before  analysis  to  provide 
evaluation  status  information  about  a  particular  function  application. 

5.3.2  Computing  Order-of-Evaluation  Information 

In  lazy  evaluation,  the  evaluation  of  an  argument  takes  place  only  when  some  occurrence  of 
the  corresponding  parameter  is  demanded.  The  order  of  evaluation  between  two  parameters 
of  a  function  can  be  determined  by  computing  the  order  of  demands  between  the  set  of 
occurrences  of  one  parameter  and  the  set  of  occurrences  of  the  other. 

Theorem  5.4  Let  f  be  a  function  defined  by  f  x\  ..  ,xn  =  bodyj,  and  let  xn, . . . ,  xio^  and 
xj i, . . . ,  Xjo(j')  be  all  of  the  occurrences  of  Xi  and  xj  in  body-f,  respectively.  Then, 
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1.  (G_before?( /,  {^ii, . . . ,  Xj0(4)},  {sji, . . . ,  Xj0(jj},  =  0  or  1  =$■  xj  is  evaluated 

before  X{  in  any  possible  application  of  f. 

Proof  :  If  ( G_before?(/,  {a4i, . .  . ,  £;0(;)},  {aji,  ■  ■  ■ ,  xjo(j)}i  e^t,t))(i)=  0  or  1  then  before  any 
demand  of  an  occurrence  x ^  of  ;r4.  there  is  a  demand  on  an  occurrence  xr,n  of  xr  Thus, 
xj  is  always  evaluated  before  x4. 

□ 

A  similar  theorem  can  be  stated  about  the  use  of  the  local  before  analysis  to  provide 
evaluation  order  information  for  the  arguments  in  a  particular  function  application. 

It  is  important  to  note  that  although  it  is  clearly  not  necessary  to  distinguish  the  in¬ 
dividual  occurrences  of  each  formal  parameter  to  perform  an  order-of-evaluation  analysis, 
there  is  no  added  cost  in  doing  so  (other  than  simply  labeling  the  occurrences).  Since  all 
occurrences  of  a  parameter  are  placed  in  the  same  set,  they  are  treated  as  a  unit  by  our 
order-of-demand  analysis.  The  cost  is  not  proportional  to  the  size  of  the  sets  of  occur¬ 
rences,  but  rather  to  the  number  of  times  the  order-of-demand  analysis  must  be  performed 
on  different  sets. 

5.3.3  Computing  Strictness  Information 

Strictness  information  about  a  function,  both  in  any  possible  application  of  the  function 
and  in  a  particular  application  of  the  function,  can  be  determined  using  order-of-demand 
analysis.  Like  all  compile-time  strictness  analyses,  the  order-of-demand  analysis  provides  a 
safe  approximation  of  the  actual  strictness  properties  of  a  function. 

Theorem  5.5  Let  f  be  a  function  defined  by  f  x\  . . .  xn  =  bodyj  and  let  xn , . . . ,  a40(^  be 
all  occurrences  of  a  single  parameter  X{  in  bodyj.  Then, 

1.  ( G_before?(  /,{$},  {a;i, ...,  £;0(4)},  envt))^  =  0  =$■  f  is  strict  in  x4,  in  any  possible 
application  of  f. 

2.  L_before?(/,  <  i . . . . ,  tn ,  {$},  {x^, . . . ,  xio^},  ehvt)  =  0  ==>  f  is  strict  in  X{  in  the  par¬ 
ticular  application  of  f  to  e\  through  en . 

Proof  :  We  sketch  the  proof  here  for  the  global  strictness  analysis.  The  proof  for  the  local 
strictness  analysis  is  similar.  (G_before?( /,  {$},  {a-4i, . . . ,  x40(4j},  chvt))^)  =  0  implies  one  of 
two  things: 

1.  At  least  one  of  Xu  . . .  x40(4j  is  demanded  during  the  any  application  of  /  to  n  arguments. 
This  is  obtained  from  the  meaning  of  0  in  B that  is  {a’ii . . .  a40(4)}  A  {$}. 
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2.  Or,  because  the  bottom  element  of  B ^  is  0,  the  fixpoint  finding  iteration  determined 
that  the  fixpoint  of  f  is  a  function  that  always  return  0,  which  would  be  the  case  if 
f  (and  thus  /)  is  everywhere  undefined  (non-terminating). 

In  either  case,  /  is  strict  with  respect  to  X{.  □ 

5.3.4  Examples 

Consider  the  following  lazy  functional  program: 

letrec  f  w  x  y  z  =  if  (w=0)  then  z+x  elseif  (y=0) 

then  z+x  else  (z+y)  +  f  (w-1)  x  (y —  1 )  z 

in  ... 

We  assume  that  f  is  of  type  ini  —*  ini  — ■>  ini  —  ini  ini.  The  definition  of  the  before 
semantic  value  /  of  f  is: 

fwxyz  =  >  %)  >  *(i))  ■- >  ( :</( l )  >2(1)  >*(!))□ 

(2/(1)  >  %)  >  2/(1)  >  (/  (™(i)  >  l,  err)  x  (j/(1)  >  l, err)  z){i))),crr) 

=  ((w(i)  >  z(i)  >  ®(i))  u  iw(i)  >2/(1)  >  *(i)  >®(i))U 

( '«•(/)  >2/(1)  >-*(1)  >  (/  (®(  1)  >  1  :</••/•)  X  >  l.f /••/•)  t)(1))),  (/•/•) 

Since  /  is  recursively  defined,  it  can  be  computed  in  a  finite  steps  using  a  fixpoint  finding 
method  as  follows: 

/(°)  w  x  y  z  =  (0,  err) 

/(1)  w  x  y  z  =  ((  w(1)  >  z(1)  >  x(1))  U  (w{1)  >  y(1)  >  z(1)  >  z(i))U 

(®(1)  >2/(1)  >  %)  >  0),  err) 

f(2)  iv  x  y  z  =  ((W(!)  >  z(1)  t>  .r(1))  U  (in(1)  >  y(1)  >  z(1)  >  z(i))U 

(W(i)  >  2/(!)  >.2(i)  >  0),  err) 

Since  / W  =  we  have  that 

fwxyz  =  (1,  Xw. (l,Xx.(l,Xy.(l,  Xz.{(w^  >  z(1)  >  a:(1))U 

(W(i)  >  2/(1)  >*(i)  >  ®(i))  >  (W(i)  >2/(1)  >-2(i)  >  0),err)))))) 

The  auxiliary  function  f  ’  of  f  is  dehned  as  follows: 


f’  wl  w2  xl  x2  x3  yl  y2  y3  zl  z2  z3  z4  =  if  (wl=0)  then  zl+xl 

elseif  (yl=0)  then  z2+x2 

else  (z3+y2)  +  f  (w2-l)  x3  (y3-l)  z4 
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Again,  notice  that  f  ’  is  not  recursive,  but  rather  calls  f.  Then,  the  definition  of  the  before 

semantic  value  f  off'  is  given  as  follows  (without  a  fixpoint  iteration). 

f  u>i  w2  x1  x2  x3  y1  y2  y3  zt  z2  z3  z4  = 

(1,  Auq.(l,  Aw2.(1,  Aair^l,  Ax2.(1,  Ax3.(1,  Ajq^l,  Ay2.(l,  A y3. 

(1,  Az^l,  Az2.(l,  Az3.(l,  Az4-((wi(i)  1>  zi(i)  >*i(i))LI 

(™i(i)  t>  2/1(1)  >  ^2(1)  >  *2(1))  u  (®i(i)  >  l/i(i)  >  %fi)  >  V 2(1)  t> 

(/  (^2(1)  >  l,  err)  x3  (y3(1)  >  l,  err)  z4){1 )),  err))))))))))))) 

Evaluation-Status  Information 

Let  ehvi  =  [f  -  /]■ 

( G -before?)  f ,  {y2},  {yl,  y3},  ehvt))^)  = 

Te[f  ’  wl  w2  xl  x2  x3  yl  y2  y3  zl  z2  z3  z 4]erir,i)(1)  =  1 

where 

env't  =  envt[ f  ’  hh>  /',  y2  (2,  err),  yl,  y3  i— >  (0 ,  err), 

w1,w2,x1,x2,x3,z1,z2,z3,z4hh>  (1,  err)] 

Thus,  we  can  conclude  that  when  y2  is  demanded,  either  yl  or  y3  has  already  been  evaluated 

and  no  run-time  check  is  required.  Similarly,  we  conclude  that  when  y3  is  demanded,  either 

yl  or  y2  has  already  been  already  evaluated  because 

( G -before?)  f ,  {y3},  {yl,  y2),  (  nv,)){l)  = 

Te[f  ’  wl  w2  xl  x2  x3  yl  y2  y3  zl  z2  z3  z4]enr'{)p)  =  1 

where 

env't  =  ehvt[ f  ’  i—  /',  y3  h-*  (2,  err),  yl,  y2  (0,err), 

wl,  w2,  xl,  x2,  x3,  zl,  z2,  z3,  z4  t— >  (1,  err)] 

And,  because 

( G_before?(f ,  {y2,  y3),  {yl},  ehvt  ))^  = 

I ,  |f  ’  wl  w2  xl  x2  x3  yl  y2  y3  zl  z2  z3  z4] env't) ^  =  1 

where 

env't  =  envt[i  ’  /',  y2,  y3  (2,  err),  yl  (0,  err), 

wl,  w2,  xl,  x2,  x3,  zl,  z2,  z3,  z4  i-»  (1,  err)] 

we  can  conclude  that  yl  is  the  occurrence  of  y  that  is  demanded  first  within  f . 
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Evaluation-Order  Information 


( G_before?(f ,  {zl,  z2,  z3,  z4},  {wl,  w2},  = 

Te[f  ’  wl  w2  xl  x2  x3  yl  y2  y3  zl  z2  z3  z4\env'i)^  =  0 


where 

env't  =  envt[f  ’  i-+  /',  wl,  w2  (0,  err),  zl,  z2,  z3,  z4  i->  (2,  err), 
xl,  x2,  x3,  yl,  y2,  y3  i— >  (l,err)] 

Thus,  we  can  conclude  that  w  is  always  evaluated  before  z  in  f . 

Similarly,  we  also  conclude  that  z  is  always  evaluated  before  x  because 

( G_before?(f ,  {xl,  x2,  x3},  {zl,  z2,  z3,  z4},  = 

Te[f  ’  wl  w2  xl  x2  x3  yl  y2  y3  zl  z2  z3  z4] env't) ^  =  0 

where 

env't  =  envt[±  ’  /',  zl,  z2,  z3,  z4  (0,  err},  xl,  x2,  x3  ^  (2,  err), 

yl,y2,y3  ^  (1 ,  err)] 

Hence,  we  conclude  that  the  parameters  to  f  are  evaluated  in  the  order  w ,  z,  x.  In  addition, 
we  can  conclude  that  w  is  evaluated  before  y,  if  y  is  evaluated  at  all.  We  cannot  conclude 
anything,  however,  about  the  relative  evaluation  order  between  x  and  y  and  between  z  and 

y- 

Strictness  Information 

(G_before?(f ,  {$},  {wl,  w2},  envt))(i)  = 

Te[f  ’  wl  w2  xl  x2  x3  yl  y2  y3  zl  z2  z3  z4] env't)(\)  =  0 

where 

env't  =  envt[f’  /',  wl,w2  (0,  err),  xl,  x2,  x3,  yl,  y2,  y3,  zl,  z2,  z3,  z4  h- 
(1,  err)] 

Then,  we  conclude  that  f  is  strict  in  w.  Similarly,  we  conclude  that  f  is  strict  in  x  and  z, 
because 

(G_before?(f ,  {$},  {xl,  x2,  x3),  ( im))j j)  = 

Te[f  ’  wl  w2  xl  x2  x3  yl  y2  y3  zl  z2  z3  z4] env't) (i)  =  0 

where 
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env't  =  ehv i [f  ’  hh>  /',xl,x2,x3  i— >  (0,  err),  wl,  w2,  yl,  y2,  y3,  zl,  z2,  z3,  z4  h-* 
(1,  err)] 


and 


( G_before?(f ,  {$},  {zl,  z2, z3, z4},  eftvy  = 

Te[f  ’  wl  w2  xl  x2  x3  yl  y2  y3  zl  z2  z3  z4]eri#f£)|C)  =  0 

where 

env't  =  CT%[f  ’  i— >  f,  zl,z2,z3,z4  i— >  (0,  err),  wl,  w2,  xl,  x2,  x3,  yl,  y2,  y3  s-* 

(1,  err)] 

However,  since 

( G_before?(f ,  {$},  {yl,  y2,  y3),  f  rm)),,)  = 

Te[f  ’  wl  w2  xl  x2  x3  yl  y2  y3  zl  z2  z3  z4\env't)(\)  =  1 

where 

env't  =  envt[f’  i— >  /',  yl,y2,y3  i— >  (0,  err),  wl,  w2,  xl,  x2,  x3,  zl,  z2,  z3,  z4 
(1,  err)] 

we  cannot  conclude  that  f  is  strict  in  y. 

5.4  Complexity  of  Before  Analysis 

The  abstract  interpretation  framework  for  order-of-demand  analysis  is  very  similar  to  the 
framework  for  strictness  analysis  except  that  a  three-element  (rather  than  two-element) 
domain  is  used  as  the  basic  abstract  semantic  domain.  Thus,  the  order  of  complexity  of 
order-of-demand  analysis  is  that  of  strictness  analysis  which  is  known  to  be  exponential 
in  the  worst-case.  The  majority  of  the  complexity  of  analysis  based  on  the  abstract  inter¬ 
pretation  technique  comes  from  finding  the  hxpoints  of  recursive  functions  in  the  abstract 
semantic  domains.  Advanced  methods  for  finding  hxpoints  on  finite  domains  can  also  be 
applied  to  order-of-demand  analysis  in  order  to  reduce  the  average-case  complexity.  The 
complexity  of  finding  hxpoints  depends  on  the  size  of  the  abstract  semantic  domains.  It  has 
been  argued  that  for  many  function,  especially  in  the  higher-order  case,  finding  hxpoints  is 
intractable  unless  the  sizes  of  the  abstract  domains  are  reduced.  Our  method  has  a  much 
lower  complexity  than  the  path  model  [11],  even  in  the  hrst-order  case. 
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5.5  Extensions  to  Other  Evaluation  Models 


So  far  we  have  described  the  order-of-demand  analysis  for  a  sequential  lazy  evaluation  model. 
In  this  section,  we  discuss  various  extensions  to  parallel  lazy  evaluation,  to  optimized  lazy 
evaluation  using  strictness  information,  and  to  non- flat  domains. 

Consider  a  parallel  lazy  evaluation  model  in  which  arguments  of  primitive  functions  may 
be  evaluated  in  parallel.  The  semantic  equations  of  the  abstract  before  semantic  function 
for  strict  primitive  functions  are  modified  as  follows: 

Te\e\  +  e2 Jenvt  =  let  l  =  Te[ei]ehut/*  same  for  e\  —  e 2  and  e\  —  e2  */ 

r  =  fele2Jenvt 

P  =  0(1)  >  r(i))  u  (r(i)  >  i(i)J 
in  (p , err) 

Consider  an  optimized  lazy  evaluation  model  in  which  all  strict  arguments  of  a  user- 
defined  function  are  evaluated  either  sequentially  or  in  parallel  before  the  execution  of 
the  function.  We  assume  that  each  function  definition  is  annotated  to  indicate  in  which 
arguments  it  is  strict.  The  semantic  equation  of  the  abstract  before  semantic  function  for 
Aaq. . . .  Xxn.e  is  modified  as  follows: 

Te{ Xx1 - A xn.ejehvt  =  let  ap  =  {fe[e\envt[xi  h-  y,]) 

in  <1,  A^/i- <1,  ■  ..Xyn.((l  >s|>  ap(1)),  ap(2))  .  .  .)) 

where 

•  In  sequential  (left-to-right)  evaluation  of  strict  arguments:  s  =  ( z/i ) ( 1 )  >.■■[>  (j/n)(i) 
where  each  Xi,  1  <  i  <  n  is  strict  parameter. 

•  In  sequential  (right-to-left)  evaluation  of  strict  arguments:  s  =  (yn){i)  >  . . .  >  ( 2/1 ) ( 1 ) 
where  each  x^,  1  <  i  <  n  is  strict  parameter. 

•  In  parallel  evaluation  of  strict  arguments:  s  =  u  (2/0(1) 

i  s.t.  xi  is  a  strict  parameter 

A  naive  way  for  the  before  analysis  to  handle  a  language  with  non- flat  domains  (due  to 
lists)  is  that  when  an  object  is  put  in  a  list  we  assume  that  it  could  be  demanded  whenever 
car  or  cdr  is  applied  to  that  list.  The  abstract  before  subdomain  Dt  for  expressions  of  type 
t  list  is  defined  as  follows: 

jjt  list  _  jjt  abstract  subdomain  for  lists 
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The  abstract  before  semantic  function  Tc  for  constants  associated  with  list-type  expressions 
is  defined  as  follows: 


Tel  nil] 

Tc[cons] 

Tc[car] 

Tc[[cdr] 

Tc[null] 


(1,  err) 

(1,  Az.(l,  \y.(2,x{2)  U  2/(2)))) 
(1,  Xx.x) 

(1,  Xx.x) 

(1,  A x.(x^,err)) 


Clearly,  more  work  remains  to  be  done  to  provide  a  more  precise  analysis  for  languages  with 
non- flat  domains. 
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Chapter  6 


Polymorphic  Invariance 


All  the  semantic  analyses  presented  in  the  preceding  chapters  have  dealt  with  a  higher-order 
functional  language  with  a  monomorphic  type  system  in  which  every  expression  is  rigidly 
typed.  Most  modern  functional  languages  adopt  a  rich  polymorphic  type  system  which  is 
more  flexible. 

In  this  chapter,  we  present  a  method,  based  on  the  notion  of  polymorphic  invariance  ([1], 
[3]),  for  applying  the  escape  analysis,  the  reference  escape  analysis,  and  the  order-of-demand 
analysis  to  a  polymorphic  language  using  the  analysis  techniques  for  a  monomorphic  lan¬ 
guage.  First,  we  describe  the  notion  of  polymorphic  invariance  of  information  and  analysis 
on  polymorphic  functional  languages.  The  proofs  of  polymorphic  invariance  of  the  escape 
analysis,  the  reference  escape  analysis,  and  the  order-of-demand  analysis  are  then  presented. 
Finally,  we  discussed  the  approach  for  analyzing  polymorphic  functions. 

6.1  Issues  in  Analyzing  Polymorphic  Functions 

Most  modern  functional  programming  languages  support  some  polymorphism  with  a  flexible 
polymorphic  type  system.  A  function  is  said  to  be  polymorphic  if  it  can  be  applied  uniformly 
to  arguments  of  a  range  of  types  more  than  one  type.  We  particularly  concentrate  on  a  kind 
of  polymorphism,  called  parametric  (generic)  polymorphism,  which  most  modern  functional 
languages  like  ML  support.  Type  expressions  are  parameterized  with  type  parameters  and 
all  type  parameters  are  universally  quantified  at  the  top  level. 

Each  semantic  analysis  for  monomorphic  languages  presented  in  the  previous  chapters 
can  be  applied  to  polymorphic  languages  by  performing  monomorphic  semantic  analysis  to 
each  monomorphic  instance  of  a  polymorphic  function.  There  are,  however,  two  problems 
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connected  with  this  approach  ([1],  [3]): 


•  The  number  of  monomorphic  instances  of  a  polymorphic  function  becomes  infinite  as 
soon  as  we  allow  structured  types  or  higher-order  functions. 

•  The  size  of  the  abstract  domain  for  structured  and  higher-order  types  goes  so  fast 
that  fixpoint  computations  become  infeasible 

Thus,  this  approach  of  performing  the  semantic  analysis  for  a  monomorphic  language  on 
each  monomorphic  instance  of  a  polymorphic  function  is  semantically  sound,  but  is  not 
satisfactory  from  a  pragmatic  point  of  view.  Analysis  of  higher-order  polymorphic  functions 
is  best  done  by  proving  a  polymorphic  invariance  result  for  the  analysis  and  then  computing 
those  non-basic  instances  of  the  abstract  functions  necessary  to  compute  all  basic  instances 
of  the  abstract  functions. 

6.2  Polymorphic  Invariance 

We  define  the  notion  of  the  polymorphic  invariance  of  properties  and  of  analyses  for  poly¬ 
morphic  languages  ([1],  [3]). 

Definition  6.1  (The  Polymorphic  Invariance  of  a  Property)  Let  P  be  a  property  of 
expressions  over  a  polymorphic  language.  P  is  said  to  be  polymorphically  invariant  if  e' 
satisfies  P  -<==>  e"  satisfies  P  for  all  e  £  Exp ,  for  all  e',  e"  in  the  set  of  possible  monomorphic 
instances  of  e. 

This  says  that  if  a  property  is  polymorphically  invariant  then  for  any  polymorphic  expression 
e,  that  property  must  hold  either  for  all  its  monomorphic  instances  or  for  none. 

Definition  6.2  (The  Polymorphic  Invariance  of  an  Analysis)  Let  A  be  an  analysis 
for  detecting  some  property.  A  is  polymorphically  invariant  if  the  application  of  the  analysis 
to  any  two  monomorphic  instances  of  a  polymorphic  function  always  yields  identical  results. 

This  means  that  if  an  analysis  is  polymorphically  invariant  then  a  polymorphic  function  can 
be  analyzed  by  considering  only  one  of  its  monomorphic  instances,  since  the  result  would 
apply  to  all  its  monomorphic  instances. 
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6.3  Polymorphic  Invariance  Proofs 


We  think  of  a  polymorphic  function  as  a  generic  notation  for  the  set  of  its  possible  monomor- 
phic  instances.  When  we  apply  the  function  in  an  actual  computation,  the  ultimate  effect 
is  that  data  of  a  determinate  base  type  is  produced,  so  we  can  regard  each  application  as 
one  of  the  monotype  instances.  This  suggest  that  sets  of  monomorphic  instances  for  some 
polymorphically  typed  expression  are  handled  in  a  semantically  natural  fashion,  and  that 
some  properties  should  be  invariant  over  such  sets. 

6.3.1  Escape  Analysis 

The  polymorphic  invariance  of  the  escape  property  of  functions  implies  that  whether  a 
parameter  escapes  from  a  function  or  not  is  independent  of  the  type  of  the  parameter.  Thus, 
given  a  polymorphic  function,  it  will  return  the  same  escape  result  on  any  two  monomorphic 
instances  of  the  function.  As  a  consequence  of  this  fact,  the  escape  analysis  problem  for 
polymorphic  functions  can  be  reduced  to  the  escape  analysis  problem  for  monomorphic 
functions.  Since  a  smaller  types  means  fewer  elements  of  that  type,  and  since  the  efficiency 
of  escape  analysis  and  similar  analyses  requiring  fixpoint  finding  is  dependent  on  the  number 
of  elements  in  the  domain,  the  proof  that  our  escape  analysis  is  polymorphically  invariant 
is  important.  By  means  of  this  reduction,  it  should  be  possible  in  practice  to  confine 
applications  of  the  escape  analysis  method  to  lower-order  types. 

We  prove  that  our  escape  analysis  is  indeed  polymorphically  invariant,  that  is,  given  a 
polymorphic  function,  it  will  return  the  identical  escape  result  on  any  two  monomorphic 
instances  of  the  function.  We  first  introduce  a  relation  among  all  possible  monomorphic 
instances  of  a  polymorphic  function  which  relates  them  with  respect  to  their  escape  property. 
Given  a  polymorphic  expression  e,  consider  any  two  of  its  monomorphic  instances  e'  and 
e"  as  follows:  e'  and  e"  are  of  type  t'  and  r" .  and  n!  and  n"  are  the  number  of  arguments 
that  the  types  t'  and  t"  can  take  before  returning  a  primitive  value,  respectively.  Let 
•u!  and  u"  be  the  values  in  the  abstract  escape  domain  D0  of  e'  and  e ",  respectively.  We 
define  a  notion  of  similarity  between  u'  and  u"  with  respect  to  the  escape  property,  written 
v!  u",  which  relates  the  escape  property  of  u'  to  that  of  u" .  We  say  that  u'  u"  iff 

(NAP k(u',  .*< i . fifc))(i)  =  (NAPfc(u",  /,. . . . , /a  J)(j) 

for  all  k  <  n,  where  n  is  the  minimum  of  n1  and  n ",  and  for  all  i  <  k,  S{  ~~  f;. 
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Lemma  6.1  Let  f  be  a  polymorphic  recursive  function  defined  as  f  x\  ...  xn  =  e  where 
e  contains  free  variables  . . .  vm.  Let  f  and  f  be  two  monomorphic  instances  of  f ,  typed 


as  follows: 

[t>i  :  :  a'm]f  :  t[  r'n r' 

L%  .  (7^  ,  .  .  .  ,  Vm  .  Om\  f  .  ...  Tn  T 

where  each  a  and  t  is  a  monotype.  For  monotyped  abstract  escape  environments  env'0  and 
env'f  that  map  each  v ;  to  an  element  in  D0  such  that  for  each  ent£[t^]  ~~  env"\yf\, 

P  ~~  /" 

where  f  =  Oe|Aa-i. . . .  Xxn.ejenv'0  and  f"  =  Oe [Aai. . . .  Xxn.eJenv'J . 

Proof  :  Let  ehv'0  and  ehv"0  be  defined  as  follows: 

ehv'0=  env'0[f  h->  0e[  /'  ] entf0\, 
ehv"=  env'f[f"  h->  Oe [  f"  ] ehv”\ 

and  let  f  and  f"  be  defined  as  follows: 

/'  =  ehv'Jf'j 

f"  =  ehvjn 

We  can  prove  /'  /"  by  fixpoint  induction  on  /,  i.e.  ehv0. 

(I)  Base  Case  of  Fixpoint  Induction  :  The  first  approximation  f'W  of  f  is  (0,  At/i - (2/1(1) ,  At/2- 
(Vi(i)  LI  1/2(1),  ■  •  •  At/„._LT/) . . .))).  The  first  approximation  /"(0)  of  f"  is  (0,  At/i.(t/1(1),  A y2. 
(f/i(i)  L  2/2(1) ,  •  -  -  A yn.±.r")  . .  .))).  Since  ±T,  ~~  Tt»,  it  holds. 

(II)  Fixpoint  Induction  Step  :  Assume  that  /'(m)  f"(m)  for  some  m  >  0.  (fixpoint 

induction  hypothesis)  Then,  we  prove  that  J,(m+1.)  /"(m+1).  This  can  be  proved  by 

structural  induction  on  expression  e.  Let  ehvjm^  and  ehvjm^  be  env'fixi  t/4-,  /'  1— ►  / ,(m)] 
and  env'f[xi  1—  t/4],  f"  ^  f"(m) ],  respectively. 

I.  Base  Case  of  Structural  Induction: 

1.  e  =  c  :  /'(m+1)  =  (0,  At/i.(t/1(1),  Xy2.  <2/i(1)  Lf/2(i),---  At/„.Oc[c])  . . .))).  Similarly, 

_  (0,  A t/!.(t/1(1),  At/2 - <2/i(i)  U  2/2(1),  •  •  •  At/„.Oc[c])  . .  .))).  Since  Oc[c]  =  Oc[c], 

it  holds. 

2.  e  =  x  :  /V+1)  =  (0,  At/!. (t/1(1),  At/2-(j/i(i)  U  t/2(i),- ••  At/n.Oe[a]  ehv'^) .  . .))  and 
j"(m+i)  =  (0,At/i.(t/1(1),At/2-(yi(i)Ut/2(i),---At/„.Oe[a-]  eht;"(m)) .  . .))).  By  the  fixpoint 
induction  hypothesis,  in  either  x  =  a;  or  a  =  /,  it  holds. 
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II.  Structural  Induction  Step:  Assume  that  /'(m)  f"(m)  for  ei,e2  and  e3-  (structural 

induction  hypothesis) 

1.  e  -  ei  +  e2  :  Since  /'(m+1)  =  (0,  A(/i.{;(/1(1),  Aj/2-(j/i(i)  U  3/2(1) ,  ■  •  •  Aj/„.(0,  err)) . . .))  and 

(0,  A 3/1-<3/1(z),  A3/2-<3/i(i)  LI  y2(1), . . .  Ay„.(0,  err))  . . .))),  it  holds.  Similarly, 
this  holds  for  e\  —  e2  and  C|  =  e2. 

2.  e  =  if  e1  then  e2  else  e3  :  =  (0,  A|/2.(t/1(1)  U  t/2(1), . . .  Aj/„.(Oe[e2] 

env'W UOe[e3]  erk^tm)))  ...)).  /"(m+1)  =  (0,  At/!. <3/1(1) ,  Aj/2.(j/1(1)Uy2(1), . . .  Ay„.(Oe[e2] 
ehvj171^  UOe[e3]  ehv0^m^)) . . .))).  By  thehxpoint  and  structural  induction  hypotheses, 
it  holds. 

3.  e  =  e!e2  :  /'(m+ 1)  =  (0,  Afo.(2/lfl),  Ay2.(j/ltl)Uy2fl), . . .  Ayn.(de[ei]  eh^m))f2)  (Oe[e2] 
e^lW)}  •  ■  ■))),  and  /"(m+1)  =  (0,  A At/2.(t/1(1)Ut/2(1), . . .  Ayn.(<9e|ei]  ehr"(m))(2) 
(Oe[e2J  ehvjm^)) . .  .))).  By  the  structural  induction  hypothesis  and  the  definition  of 

it  holds. 

4.  e  =  lambda(x).e1  :  /V+B  =  (0,  \yi~{y%(j),  Aj/2.(y1(1)  Ut/2(1),.,.  A?/„.(F',  At/.Oe[ei] 
eh^(m)[i4  h-  y4])  )  .  . .))),  and  /"("v'  n  =  (0,  Afo.(j/1(1),  Aj/2.(j/lfl)  U  t/2(1), . . .  A yn.(V", 
AfoOe[ei]  env"0^m\xi  h->  yt]}  )...))).  Since  env0^m\z\)  ~~  ehr"(m)[^]),  F'  =  F". 
Then,  by  the  structural  induction  hypothesis,  it  holds. 

□ 

The  above  lemma  says  that  all  possible  monomotype  instances  of  a  polymorphic  function 
are  similar  with  respect  to  escape  property  of  their  arguments  and  local  objects.  Based 
on  this  fact,  we  prove  that  both  the  global  and  focal  escape  analyses  are  polymorphically 
invariant . 

Theorem  6.1  (Global  Escape  Analysis)  Let  f  be  a  polymorphic  function  of  arity  n, 
and  let  f  and  f"  be  any  two  monomorphic  instances  of  f.  Assume  that  env'  and  env"  are 
abstract  escape  semantic  environments  that  map  f  and  f"  to  elements  of  D0,  respectively. 
Then,  for  1  <  i  <  n, 

G-escap  el(f  ,i,envr)  =  G_escap  el(f",i,env") 

Proof  :  From  the  definition  of  the  global  escape  test  function, 

G .escape? ( /',  i,  env')  =  (6e{f  x1  . . .  ij  env'[ xt  1—  2/4])(1) 

where  y\  =  (1,TFT»)  and,  for  j  <  n  and  j  7?  i ,  y'-  =  (0,  WT>).  Let  f'  =  env'lfj.  Then,  by 
the  definition  of 
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G .escape? (f ,  i,  env')  =  ( NAP„( j',  y[, . . . ,  y'n)){1). 


Similarly, 

G .escape? (/",  i,  env')  -  (NAP „(/",  y", y")\ i) 

where  f"  =  eri^"[/],  y"  =  (1,LPT*”)  and,  for  j  <  n  and  j  7?  i ,  y"  =  (0,Wtj).  By  the 
definition  of  the  worst-case  escape  function  IT,  y'k  y'f  for  all  1  <  k  <  n.  Thus,  by  the 
Lemma  6.1,  f'  f".  Then,  by  definition  of  we  have  that  (NAP n{f',y%  ■  ■  ■  ■ ))( ij 
=  (NAP„(/,/,  y”, . . . , ;(/"))(!).  Thus,  we  conclude  that 

G_escape?(/',  *,  env1)  =  G_escape?(/",  i,  env"). 

□ 


Theorem  6.2  (Local  Escape  Analysis)  Let  f  be  a  polymorphic  function  of  arity  n  in 
an  application  f  e  1  ...  en.  Let  f  and  f"  be  any  two  monomorphic  instances  of  f ,  and  e\ 
and  e"  be  two  monomorphic  instances  of  e, .  Assume  that  env'  and  env "  are  abstract  escape 
semantic  environments  that  map  f  and  all  free  identifiers  within  e\,  and  f"  and  all  free 
identifiers  within  e”  to  elements  of  D0,  respectively.  Then,  for  1  <  i  <  n, 


L_escap e?(//,  i.  c\. . . . ,  e'n,  env') 


L^escape?  ( f",  i ,  e", . . . ,  e 


u 

n  5 


env") 


Proof  :  This  can  be  proved  in  a  similar  way  to  the  polymorphic  invariance  proof  of  the 
global  escape  analysis.  □ 


6.3.2  Refined  Escape  Analysis 

The  polymorphic  invariance  of  the  refined  escape  property  of  functions  implies  that  the 
extent  of  a  parameter  which  does  not  escape  from  the  function  call  is  independent  of  the  type 
of  the  parameter.  Thus,  given  a  polymorphic  function,  it  will  return  the  same  refined  escape 
result  on  any  two  monomorphic  instances  of  the  function.  The  polymorphic  invariance  of 
the  refined  escape  analysis  means  that  given  a  polymorphic  function,  it  will  return  the 
same  refined  escape  result  for  any  two  monomorphic  instances  of  that  function.  Actually, 
the  refined  escape  analysis  is  polymorphically  invariant  when  it  is  stated  the  following  way: 

Given  a  polymorphic  function,  the  number  of  spines  of  a  parameter  that  does 
not  escape  from  the  function  application  is  the  same  for  any  two  monomorphic 
instances  of  the  function. 
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From  this  point  of  view,  we  will  prove  that  our  refined  escape  analysis  is  indeed  polymor- 
phically  invariant.  We  introduce  a  relation  among  all  possible  monomorphic  instances  of 
a  polymorphic  function  which  relates  them  with  respect  to  their  refined  escape  property 
as  stated  above.  Given  a  polymorphic  expression  e,  consider  any  two  its  monomorphic 
instances  e'  and  e"  as  follows:  e'  and  e"  are  of  type  t'  and  t" .  and  n!  and  n"  are  the 
number  of  arguments  that  the  types  t'  and  t"  can  take  before  returning  a  primitive  value, 
respectively.  Let  u'  and  u"  be  the  values  in  the  abstract  refined  escape  domain  Dp  of  e' 
and  e",  respectively.  We  define  a  notion  of  similarity  between  u'  and  u"  with  respect  to  the 
refined  escape  property,  written  v!  ~~  u ",  which  relates  the  refined  escape  property  of  v! 
to  that  of  u" .  We  say  that  v!  ~~  u"  iff 

NAP  k{u',s1,. .  ..*a-))(i)  =  NAP  a-(u",  ti, . .  .,4))(  l)  =  (M) 


or 


NAP„(u  ,  5^5 . . . ,  5a) —  NAP n(  u  ,  1 . . ,  t]z —  1  and 
d'  -  NAP„(u',s1, . .  -  ,s*))'(i)(2)  =  d"  ~  NAP„(u",  fi, . .  v,4))(i)(2) 

for  all  k  <  n  where  n  is  the  minimum  of  n'  and  u",  for  all  j  <  k ,  =  (1,  d'-)  and  = 

(1,  dj)  where  d'j  and  d'j  is  the  number  of  spines  of  the  jth  parameter  of  that  n  parameters, 
for  all  l  7^  j  and  l  <  k ,  =  (0,  0),  and  for  all  i  <  k ,  s;  ~~  ti. 

Lemma  6.2  Let  f  be  a  polymorphic  recursive  function  defined  as  f  xi  . . .  xn  =  e  where 
e  contains  free  variables  Vi . .  ,vm.  Let  f  and  f  be  two  monomorphic  instances  of  f ,  typed 
as  follows: 

[V!  :  o[, . . . ,  :  a'm}f  :  t{  —  t' 

r„,  .  „  .  „u  i  fii  .^11 

where  each  o  and  t  is  a  monotype.  For  monotyped  abstract  refined  escape  environments  env'p 
and  envp  that  map  each  Vi  to  an  element  in  Dp  such  that  for  each  Vi,  ~~  env"\yi\, 

r  ~F~  f" 

where  fi  =  Pe[Aa-i. . .  .A  xn.e\env'p  and  f"  =  Pe[Aa’i. . . .  Xxn.ejenvp. 

Proof  :  Let  env'p  and  ehv"  be  defined  as  follows: 

ehv'p=  envp [fi  ^  Pe[  fi  }ehv'p], 
ehv”=  envp[f"  h->  Pe[  f"  ]env"\ 
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and  let  f  and  f"  be  defined  as  follows: 


f  =  env'plfj 

I"  =  env;m 

We  can  prove  this  by  fixpoint  induction  on  /,  i.e.  envp. 

(I)  Base  Case  of  Fixpoint  Induction  :  The  first  approximation  f'(°)  of  f'  ((0,  0),  Ar/i^r/j^),  Ar/2 - 

<2/i(i)  LI  2/2(1) ,  ■  ■  ■  ■)))■  The  first  approximation  /"(0)  of  f"  ((0,0),  A yi.(yni),  A y2. 

(2/1(1)  U  1/2(1), . . .  A yn.±T»)  .  . .))).  Since  _LT/  ~~  ±T/,  it  holds. 

(II)  Fixpoint  Induction  Step  :  Assume  that  f'(m)  ~~  f"(m)  for  some  to  >  0.  (fixpoint 

induction  hypothesis)  Then,  we  prove  that  f\m+1)  rS~  /"(m+ 1)_  This  can  be  proved  by 
structural  induction  on  expression  e.  Let  env^m^  and  envj'm^  be  envp[xi  1— ►  j/4-,  f  1— ►  /^m^] 
and  envp\xi  y4],  /"  /"(H],  respectively. 

I.  Base  Case  of  Structural  Induction: 

1.  e  =  c  :  /'(m+1)  =  ((0,  0),  A yi-(y1{1),  A y2.  (2/1(1)  U  2/2(1.),  ■  •  •  A yn-Pc{c\)  ■  ■  ■)))■  Similarly, 
f"{m+ 1)  =  ((0,  0),  Ai/i- (2/1(1) ,  At/2.(t/i(i)  U  Ay„.Pc[c]) . . .))).  Thus,  clearly  it 

holds. 

2-  e  =  x  :  /'(m+1)  =  ((0,  0),  A 2/1.(2/1(1),  At/2-(s/i(i)  U  2/2(i.),  •  •  •  Xyn.Pe{x\  env^)  . . .))  and 
f"{m+ 1)  =  ((0,0),  A2/!.(2/1(1),  A2/2.(i/1(1)  U  2/2(1.),  -  -  -  A yn.Pe[x\  enw"(m))  . . .))).  By  the 
fixpoint  induction  hypothesis,  in  either  r  =  i,-  or  1  =  /,  it  holds. 

II.  Structural  Induction  Step:  Assume  that  f'(m)  rSr -j  f"im)  for  ej,  e2  and  63.  (structural 
induction  hypothesis) 

1.  e  =  ei+e2  :  Since  /'(™+1)  =  <<0,  0),  A1/1. (t/1(1) ,  Xy2.(y1^)Uy2{rj, .  ■  ■  Xyn.((Q,0),err)) . . .)) 
and  /'V+1)  =  ((0,  0),  A 2/1.. ^(i),  Aj/2-<2/i(i)  L  y2(i),  ■  •  ■  Xyn.((0,  0),  err)) . .  .))),  it  holds. 
Similarly,  this  holds  for  ei  —  e2  and  e\  =  e2. 

2.  e  =  if  e1  then  e2  else  e3  :  /'(m+1)  =  ((0,  0),  Xy1.(y1(1),  A3/2- (2/1(1) U2/2(i) ,  •  •  •  Ayn.(Pe[e2] 
ehn^m)  U  Pe[e3]  erh$m)))  . . .))  and  /"(m+1)  =  ((0,  0),  A 2/1.(2/1(1),  A2/2-<2/i(i)  L  2/2(1),  ■  ■  ■ 
At/n.(Pe[e2]  envj^  l_lPe[e3]  envp^m^))  .  . .))).  By  the  fixpoint  and  structural  induction 
hypotheses,  it  holds. 

3.  e  =  e!e2  :  =  ((0,  0),  Xy1.(y1{1),  Xy2.(y1{1)  U  2/2(1),  •  •  •  Ay„.(Pe[ei]  envp^)(2) 

(Ale 2]  ehv'j m'>))  ...))).  /”(m+1)  =  ((0,  0),  A 2/1-(2/1(1),  Aj/2-(2/i(i)  U  2/2(1) ,  ■  ■  ■  Ayn.(Pe[ei] 
envp(m  ^)(2)  (Peleij  ehvj'’"1})) . . .))).  By  the  structural  induction  hypothesis  and  the 
definition  of  it  holds. 
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4.  e  =  lambda(a;).ei  :  /'(m+1)  =  ((0,0),  Xyi.(y1{1),  Xy2.(y1(1)Uy2^), . . .  Xyn.(V' ,  Xy^^J 
eh'ojm\xi  h-  yi\)  )  .  . .))),  and  f"(m+1)  =  ((0,0),  Xyi-iy^g),  Ay2-(j/i(i)Uy2(1), . . .  A yn.{V", 
\y.Pe{eil  ehv"p(m\xi  >->  yt]}  )...))).  Since  env'jm\z\)  ~~  F'  =  F". 

Then,  by  the  structural  induction  hypothesis,  it  holds. 

□ 

The  above  lemma  says  that  all  possible  monomorphic  instances  of  a  polymorphic  function 
are  related  with  respect  to  refined  escape  property  of  their  arguments  and  local  objects. 
Based  on  this  fact,  we  prove  that  both  the  global  and  local  refined  escape  analyses  are 
polymorphically  invariant . 

Theorem  6.3  (Global  Refined  Escape  Analysis)  Let  f  be  a  polymorphic  function  of 
arity  n,  and  let  f  and  f"  be  any  two  monomorphic  instances  of  f .  Assume  that  env'  and 
env"  are  abstract  refined  escape  semantic  environments  that  map  f  and  f"  to  elements  of 
Dp,  respectively.  Then,  for  1  <  i  <  n, 

G_rescape?(/',  i,  env1)  =  (0,0)  4=4-  G_rescape?(/",  i,  env")  =  (0,0) 


or 


G _rescape? (/',  i,  env')  =  (1  ,k')  4=>  G_rescap el(  f",i,env")  =  (1  ,k") 

such  that  s[  —  k1  =  s'-  —  h"  where  and  s'-  are  the  number  of  spines  of  the  ith 

parameter  of  f  and  f" ,  respectively. 

Proof  :  From  the  definition  of  the  global  refined  escape  test  function, 

G_rescape? ( /',  i,  env1)  =  (Pe{f  x1  . . .  xn\  env'[xi  j/4])(1) 

where  y[  =  ((1,  s'f),  WT')  and,  for  j  <  n  and  j  i,  y’-  =  ((0,0)lFb).  Let  /'  =  env'\fj. 
Then,  by  the  definition  of  Pe,  Then, 

G_rescape?  (/',  i,  env')  -  (NAPn(/,7  y[, . .  .,y(i))(1). 

Similarly, 

G_rescape? ( /",  i,  env')  =  (NAP „(/",  y", . . . , ;(/"))(.,) 

where  f"  =  env"\f\,  y"  =  ((1,  s'f),  WTi)  and,  for  j  <  n  and  j  ±  i,  y”  =  ((0,0)IF4).  By 
the  definition  of  the  worst-case  escape  function  W,  y[  ~~  y'f  for  all  1  <  k  <  n.  Thus,  by 
the  Lemma  6.2,  f  ~~  f".  Then,  by  definition  of  we  have  that 

NAP„(/',  y[,  =  NAPn( /",  y'i,  =  (0, 0) 
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or 


(NAP  n(j>,y'1,...,y'n))(1)(1)  =  (NAP„(  /",  y'fi . . . ,  y"))(1)(2)  =  1 
and 

S'  -  (NAP (NAP„(/«, »"))(1)(2) 

Thus,  we  conclude  that  it  holds.  □ 

Theorem  6.4  (Local  Refined  Escape  Analysis)  Let  f  be  a  polymorphic  function  of  ar- 
ity  n  in  an  application  f  . . .  en.  Let  f  and  f"  be  any  two  monomorphic  instances  of  f, 
and  e\  and  e"  be  two  monomorphic  instances  of  ej.  Assume  that  env1  and  env"  are  abstract 
escape  semantic  environments  that  map  f  and  all  free  identifiers  within  e\,  and  f"  and  all 
free  identifiers  within  e "  to  elements  of  Dp,  respectively.  Then ,  for  1  <  *  <  n, 

L_rescape?(//,  i,  efi  .  ..,e'n,env')  =  (0,0) 

L_rescape?(///,  e'/, . . . ,  e^,  env")  =  (0,  0) 


or 


L_rescape?(//,i,e/1, .  ..,e'n,env')  =  (0,0)  =  (1,  k') 

-<=4-  L.rescape? (/",  i ,  e", . . . ,  e",  env")  =  (0,  0)  =  (1,  k") 
such  that  —  k1  =  s"  —  k"  where  .s'  and  s "  are  the  number  of  spines  of  e\  and 
e",  respectively. 

Proof  :  This  can  be  proved  in  a  similar  way  to  the  polymorphic  invariance  proof  of  the 
global  refined  escape  analysis.  □ 

6.3.3  Reference  Escape  Analysis 

The  polymorphic  invariance  of  the  reference  escape  property  of  functions  says  that  whether 
a  reference  to  a  heap  allocated  object  escapes  a  call  to  a  polymorphic  function  or  not  is 
independent  of  the  type  of  the  object  to  which  the  reference  is  pointing.  This  means  that 
given  a  polymorphic  function,  reference  escape  analysis  will  provide  the  same  reference 
escape  result  on  any  two  monomorphic  instances  of  that  function. 

We  prove  that  our  reference  escape  analysis  is  indeed  polymorphically  invariant.  We 
introduce  a  relation  among  all  possible  monomorphic  instances  of  a  polymorphic  function 
which  relates  them  with  respect  to  their  reference  escape  property.  Given  a  polymorphic 
expression  e,  consider  any  two  its  monomorphic  instances  e1  and  e"  as  follows:  e1  and  e" 
are  of  type  t’  and  t" .  and  n'  and  u"  are  the  number  of  arguments  that  the  types  t'  and  t" 
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can  take  before  returning  a  primitive  value,  respectively.  Let  v!  and  u"  be  the  values  in  the 
abstract  reference  escape  domain  Dr  of  e'  and  e",  respectively.  Let  v!  and  u"  be  the  values 
in  the  abstract  reference  escape  domain  Dr  of  e'  and  e" .  respectively.  We  define  a  notion  of 
similarity  between  u'  and  u"  with  respect  to  reference  escape  property,  written  u'  ~~  u ", 
which  relates  the  reference  escape  property  of  u'  to  that  of  u" .  We  say  that  u'  ~~  u"  iff 

(1AP k(u',  51; . . . ,  *A-)){.1)(1)  =  (NAP k(u",  ti, . . . ,  4))(  1)(1) 

for  all  k  <  n  where  n  is  the  minimum  of  n'  and  n" ,  and  for  all  i  <  k,  s /  ~~ 

Lemma  6.3  Let  f  be  a  polymorphic  recursive  function  defined  as  f  x%  ...  xn  =  e  where 
e  contains  free  variables  Vi . .  ,vm.  Let  f  and  f  be  two  monomorphic  instances  of  f,  typed 
as  follows: 

l''h  :  v't . rm  :  a'm]f  :  t{  -*  . . .  -+  r'  —  t' 

[V1  ■  j  ■  ■  ■  j  vm  ■  Um\J  '  T1  ■  ■  ■  Tn  T 

where  each  a  and  r  is  a  monotype.  For  monotyped  abstract  reference  escape  environments 
env'r  and  env'f  that  map  each  v /  to  an  element  in  Dr  and  for  each  Uj,  ~~  enu"[u!], 

respectively, 

r  ~~  r 

where  f'  =  i?e|Aa-i. . .  .\xn.e\env'r  and  f"  =  i?e[Aai. .  .  .A xn.e\env'f. 

Proof  :  Let  ehv'T  and  ehv'f  be  dehned  as  follows: 

ehv'r=  env'fif  i -?  Re{  f  \ehv'r\, 
ehv''=  env'f[f"  >—  Re{  f"  ] ehv"] 

and  let  f'  and  f"  be  dehned  as  follows: 

/'  =  ehv'r{f'} 

/"  =  ehv'fin 

We  can  prove  f  ~~  f"  by  bxpoint  induction  on  /,  i.e.  ehvr. 

(I)  Base  Case  of  Fixpoint  Induction  :  The  first  approximation  f'W  of  f  is  ((0,  0),  At/2- 

<3/i(i)  L-l  2/2(1) ,  -  ■  -  A  Vu-L-t1)  ■  ■  ■)))•  The  first  approximation  /"(0)  of  f"  is  ((0,0),  A  t/i-(t/1(1),  A  t/2- 
(3/i(i)  LI  3/2(1) 5  ■  ■  •  Xyn.±T")  ■  - .))).  Since  J_T/  ~~  T-/,  it  holds. 

(II)  Fixpoint  Induction  Step  :  Assume  that  /'(m)  rJ~  /"(m)  for  some  m  >  0.  (hxpoint 
induction  hypothesis)  Then,  we  prove  that  f'(m+1)  rJr ^  f'(m+1).  This  can  be  proved  by 
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structural  induction  on  expression  e.  Let  ehvj-m^  and  envr^m^  be  env'r[xi  i->  y,t ,  f  hh>  / ,(m)] 
and  env'J[ xt  h->  yt],  f"  h-»  /"(H],  respectively. 

I.  Base  Case  of  Structural  Induction: 

1.  e  =  c  :  /V+1)  =  ((0,  0),  Xy1.(y1{1),  X y2.  <2/1(1)  U  y2(i),  ■  ■  ■  A yn.Rc{c\) . . .))).  Similarly, 

f”{m+ 1)  =  <<0,  0),  A3/a.<3/1(1j,  Ay2-<3/iXl)  u  Xyn.Rclc})  . . .))).  Thus,  clearly  it 

holds. 

2.  e  =  x  :  /'(m+ !)  =  ((0,  0),  Xy1.(y1(1y  Xy2.{y1(1)  U  y2{1y . . .  Xyn.Re{x ]  env’W)  .  . .))  and 
j"(m+i)  =  ^o,  0),  \yi.(yiVy,  A y2.(y1(1)  U  y2(1y . . .  Xyn.Re\x\  env”^) ...))).  By  the 
fixpoint  induction  hypothesis,  in  either  x  =  x^  or  x  =  /,  it  holds. 

II.  Structural  Induction  Step:  Assume  that  f'(m)  /"(m)  for  ei,e2  and  e 3.  (structural 

induction  hypothesis) 

1.  e  =  e!+e2  :  Since  =  ((0,0),  A yi-{y1(1y  Xy2.(y1{1)Uy2{1y  . . .  Xyn.((0,  0),  err)) .  . .)) 

and  '  l!  =  ((0,  0),  Aj/!. <j/1(1) ,  At/2.(t/1(1)  U  j/2(1), . . .  Ay„.((0,  0),  err)) . . .))),  it  holds. 
Similarly,  this  holds  for  ei  —  e2  and  e\  =  e2. 

2.  e  =  if  e!  then  e2  else  e3  :  n  =  ((0,  0),  Xy1.(y1(1y  Xy2.(yyyUy2{1y . . .  Xyn.(Re{e2J 

ehv'^  U  Rele3J  ehv'^)) . . .))  and  /"(m+1)  =  ((0,  0),  Xy1.{y1(1y  Xy2.{yl(1)  U  y2(1y  . . . 
Xyn.(Rele2J  envr^m^  Ui?e[e3]  ehvr^m^))  .  . .))).  By  the  fixpoint  and  structural  induction 
hypotheses,  it  holds. 

3.  e  =  %e2  :  /V+B  =  ((0,  0),  Xy^y^y  Xy2.tyy1yL)  U  y2{1y . . .  Ay„.(^e[ei]  efiv'r(rn'>)(2) 
(^hl  ehv'^))  . . .))).  /"(m+1)  =  ((0,0),Aj/1.(2/1(1),A|/2.(j/1(1)Ut/2(1),...  Ay„.(^e[ei] 
ehvr^m  '  )(2)  (-Ke[e2]  f  rir  ,.*"*)}} . . .))).  By  the  structural  induction  hypothesis  and  the 
definition  of  it  holds. 

4.  e  =  lambda(a:).ei  :  /'(m+1)  -  ((0,0),  Ai/i.( ,  Xy2.(yyyUy2^y  . . .  X yn.(V',  At/.^e[ei] 

env^lxi  h-.  j/i])  )  .  . .))),  and  =  ((0,0),  Xyt^yyy,  Xy2.{y1(yUy2(1y  . . .  X  yn.(V", 

X y.Re{ei]  efiv"r^m\x,  h->  yt])  )...))).  Since  env^lz})  ~~  ehv"T^m\z\)-3  F'  =  F". 
Then,  by  the  structural  induction  hypothesis,  it  holds. 

□ 

The  above  lemma  says  that  all  possible  monomorphic  instances  of  a  polymorphic  function 
are  similar  with  respect  to  reference  escape  property  of  references  created  within  them. 
Based  on  this  fact,  we  prove  that  both  the  global  and  local  reference  escape  analyses  are 
polymorphically  invariant. 
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Theorem  6.5  (Global  Reference  Escape  Analysis)  Let  f  be  a  polymorphic  function 
of  arity  n,  and  let  f  and  f"  be  any  two  monomorphic  instances  of  f.  Assume  that  env'  and 
env"  are  abstract  reference  escape  semantic  environments  that  map  f  and  f"  to  elements 
of  Dr,  respectively.  Then,  for  1  <  i  <  n  and  for  1  <  j  <  o(i), 

G_refescape?(//,  *,  j,  enif)  =  G _refescape?(///,  i,j,  env"). 

Proof  :  Let  f'a  and  f'f  be  the  auxiliary  functions  for  f  and  f".  respectively.  From  the 
definition  of  the  global  reference  escape  test, 

G_refescape?  (f ,  i,  j,  env')  =  ( Re[f'a  xn  ...  xno{n)Jenv'[f'a  f'a,xtJ 

where  f  =  Re{f'\env\  /'  =  Relf'Jenv'[f  ^  /'],  yT  =  <(1,  s'f),  WT'i),  for  all  k  <  o(i )  and 
k  ±  j ,  y'ik  =  ((0,  0),  WTi),  and  for  all  1  <  m  <  o(l )  and  l  ±  i,  y'lm  =  ((0,  0),  WT‘).  Then,  by 
the  definition  of  Re, 

G_refescape?( /',  i,j,  env1)  =  (NAP m( /',  J/n,  •  ■  • ,  <o(n)))(1)(1) 
where  m  =  Similarly, 

G_refescape? ( /",  i,j ,  env")  =  (NAP m(/",  y'{lr . . . ,  2/"o(n)  ))(i)(i) 

where  f"  =  Re[f"\env" ,  /"  =  Relffjenv"[f"  /"],  y'h  =  ((1,  s'f),  WT"),  for  all  k  <  o(i ) 
and  k  7^  j,  y"k  —  ((0,  0),  WTi'),  and  for  all  1  <  m  <  o(l )  and  l  ^  i ,  y"m  =  ((0,  0),  WT"). 
By  Lemma  6.3,  /'  ~~  f"  and  thus  f'a  ~~  f'f.  By  the  definitions  of  the  worst-case  escape 
function  W,  y[-  ~~  y'fj  for  all  1  <  i  <  n  and  1  <  j  <  o(i).  Then,  by  the  definition  of 

NAP  y\  t, ...,  y'no{n)\ i)  =  NAPm(/",  yfu  ...,  y”o{n)){1). 

Thus,  we  conclude  that 

G_refescape? (/',  i,  j ,  env')  =  G_refescape? ( f",  i,  j ,  env") 

□ 

Theorem  6.6  (Local  Reference  Escape  Analysis)  Let  f  be  a  polymorphic  function  of 
arity  n  in  an  application  f  e  1  ...  en .  Let  f  and  f"  be  any  two  monomorphic  instances 
of  f ,  and  e\  and  e"  be  two  monomorphic  instances  of  e^.  Assume  that  env'  and  env"  are 
abstract  escape  semantic  environments  that  map  f  and  all  free  identifiers  within  e[,  and  f" 
and  all  free  identifiers  within  e "  to  elements  of  Dr,  respectively.  Then,  for  1  <  i  <  n  and 
for  1  <  j  <  o(i), 
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L_refescape?  (/',  i,  j,  env' )  =  L_refescape?  (/",  i,  j,  e'{, . . . ,  e",  env ") 

Proof  :  This  can  be  proved  in  a  similar  way  to  the  polymorphic  invariance  proof  of  the 
global  reference  escape  analysis.  □ 

As  a  consequence  of  this  fact,  the  reference  escape  analysis  problem  for  polymorphic 
functions  can  be  reduced  to  the  problem  for  monomorphic  functions.  The  reference  escape 
analysis  algorithm  need  only  be  applied  to  the  simplest  monomorphic  instance  of  a  function. 
Smaller  types  implies  fewer  elements  of  that  type,  and  the  efficiency  of  reference  escape 
analysis  and  similar  analyses  requiring  fixpoint  finding  is  dependent  on  the  number  of 
elements  in  the  domain. 

6.3.4  Order-of-Demand  Analysis 

The  polymorphic  invariance  of  the  order-of-demand  property  of  functions  implies  that  the 
order  of  demand  between  parameters  of  a  function  during  the  evaluation  of  the  function 
is  independent  of  the  type  of  the  parameters.  Thus,  given  a  polymorphic  function,  it  will 
return  the  same  escape  result  on  any  two  monomorphic  instances  of  the  function. 

We  prove  that  our  before  analysis  is  indeed  polymorphically  invariant.  We  introduce  a 
relation  among  all  possible  monomorphic  instances  of  a  polymorphic  function  which  relates 
them  with  respect  to  their  order-of-demand  property.  Given  a  polymorphic  expression  e, 
consider  any  two  its  monomorphic  instances  e'  and  e"  as  follows:  e'  and  e"  are  of  type  t' 
and  r" .  and  n'  and  n"  are  the  number  of  arguments  that  the  types  r'  and  t"  can  take 
before  returning  a  primitive  value,  respectively.  Let  v!  and  u"  be  the  values  in  the  abstract 
before  domain  1) /  of  e'  and  e",  respectively.  We  define  a  notion  of  similarity  between  u!  and 
u"  with  respect  to  order-of-demand  property,  written  u!  ~~  u ",  which  relates  the  before 
property  of  u'  to  that  of  a" .  We  say  that  u!  ~~  u"  iff 

(NAP  k(u',sr, .  ..,sk))(1)  =  (NAP  k(u",tu . .  -,tk))(i) 

for  all  k  <  n  where  n  is  the  minimum  of  n'  and  n" .  and  for  all  i  <  k,  Sj  ~~  tj. 

Lemma  6.4  Let  f  be  a  polymorphic  recursive  function  defined  as  f  x %  ...  xn  =  e  where 
e  contains  free  variables  rq  . . .  vm.  Let  f  and  f  be  two  monomorphic  instances  of  f,  typed 
as  follows: 

[vi  vm:  a  'm]f'  :  t{  —  r' 

[®i  :  ,  •  •  ■ ,  :  cr"  ]/"  :  t{'  r"  ->  t" 
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where  each  a  and  t  is  a  monotype.  For  monotyped  abstract  before  environments  env[  and 
env'f  that  map  each  v_i  to  an  element  in  Dt  and  for  each  Vi .  en^[»i]  ~~  env'f\yf\,  respec¬ 
tively, 

r  ~~  f" 

where  f  =  Te[ Xxi. . .  .A xn.e\env[  and  f"  =  Te[Aa-i. . .  .A xn.e\env'f . 

Proof  :  Let  ehv't  and  env'f  be  defined  as  follows: 

ehv't=  env[[f  h->  Te[  f  jenvf], 
env'f  =  env'f  [f"  i—  Te  |  f"  Jehv'f ] 

and  let  f  and  f"  be  defined  as  follows: 


/'  =  env'tlfi 
f"  =  efivflf"} 


We  can  prove  /'  ~~  f"  by  fixpoint  induction  on  /,  i.e.  ehvt. 

(I)  Base  Case  of  Fixpoint  Induction  :  The  first  approximation  f'(°)  of  f'  is  (1,  At/i .  ( 1 ,  Aa/2- 

(1, .  . . \yn.±Ti) . . .))).  The  first  approximation  /"(0)  of  f"  is  (1,  Xyifl,  A  y2.  (1, , . .  Xyn.FTn)  . .  .))). 
Since  T  /  r-o  ±  // ,  it  holds. 

'  T  ’ 

(II)  Fixpoint  Induction  Step  :  Assume  that  f'(m)  ~~  f"(m)  for  some  m  >  0.  (fixpoint 

induction  hypothesis)  Then,  we  prove  that  f\m+1)  This  can  be  proved  by 

structural  induction  on  expression  e.  Let  ehv^m^  and  ehvt^m'  be  env't[xi  j/4-,  f  1— ► 

and  env'f  [xi  yt\,  f"  respectively. 

I.  Base  Case  of  Structural  Induction: 


1.  e  =  c  :  /'(-+1)  =  (l,Xy1.(l,Xy2.  (1,...  \yn.%[c\) . . .))).  Similarly,  f"{m+1)  = 
(1,  A i/i . ( 1 ,  Xy2.{l,  ■  •  •  A yn.Tc[cf]  . . .))).  Thus,  clearly  it  holds. 

2.  e  =  x  :  /'(m+1)  =  (1,  Aa/i. ( 1 ,  Xy2.{l,  ■  ■  ■  Xyn.fe{xj  env}^)  ...)).  /"(m+1)  =  (1,  Aya.(ls 
Xy2.{\, . .  .  Aj/n.Te[a]  ehvty  )  . . .))).  By  the  fixpoint  induction  hypothesis,  in  either 
x  =  Xi  or  x  =  /,  it  holds. 

II.  Structural  Induction  Step:  Assume  that  f'(m)  rJ~  /"(m)  for  ei,e2  and  63.  (structural 
induction  hypothesis) 

1.  e  =  ei+e2  :  Let  l'  =  Te[ei]ehu/m'  and  r'  =  Te\e2\ehv}rn'> .  Let  l "  =  Te\ei\ehvt  ^  and 
r"  =  fele2}ehvt  (m).  Then.  /'("*;  n  =  (1,  Xytfl,  Xy2.(l, . . .  Xyn.(l'^  >  err))  . . .)) 
and  /"(m+1)  =  (l,Xy1.(l,Xy2.(l,. . .  Xyn.{l ^  t>  r'f^y  err)) . . .)}).  By  the  structural 
induction  hypothesis  and  the  definition  of  it  holds. 
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2.  e  =  if  ei  then  e2  else  e 3  :  Let  p'  =  Te[ei]erit>j^m\  c'  =  Te[e2]erant^m' ,  and  a'  = 
Te[e3]ennt(m' .  Let  p"  =  fe\e1\envt  ('m\  c"  =  Te[e2]em;/m\  and  a"  =  Te[e3]eriut  (m' . 

Then,  /'(m+1)  =  (1,  A^a.<l,  Ay2-<1,  ■  ■  ■  Ap„.(p'(1)  >  c'(1),  c'(2))  |_|(P(i)  >  a'(i)’  a(2)))  •  •  •)) 
and  /"(m+1)  =  (1,  Ap!.(l,  Ap2-(1,  ■  ■  ■  Ay„.,(p"1^  >  c"1)7  c"2))  U(p"i)  >  «(i)5  a"2)))  ■  •  •)))■ 
By  the  structural  induction  hypothesis  and  the  definition  of  it  holds. 


3.  e  =  eje2  :  Let  /'  =  7:f  [cif' ap'  =  /(2)(Te[e2]erint(m)).  Let  /"  =  Tele1\ehvt  (m)), 
ap"  =  /(2)(Te[e2]efint(m)). 

Then,  =  <1,  Api.(l,  Ap2-(1,  ■  ■  ■  A yn-{f[^  >  ap'(1),ap'(2])) ...))),  and  /"(m+1)  = 

(1,  At/i.(l,  Aj/2-(1,  ■  •  •  A yn ■(/[[)  t>  aP(i)j  aP(2)))  ••■)))■  By  the  structural  induction  hy¬ 
pothesis  and  the  definition  of  r-w'  r^J  ^  it  holds. 


4.  e  =  lambda(x).e1  :  /'(m+1)  =  (1,  Api.(l,  Ap2-(1,  •  ■  ■  Aj/n.(l,  Aj/.Te[ei]  ehvt(-m)[xt  1— 
Vi])  )•••))),  and  /"(m+ B  -  (l,Api.(l,Ap2-(lv--  Ay„.(l,  Aj/.Te[ei]  ehnt(m)[a-4  e->  p4]) 
) . .  .))).  enVf171'  [2])  rJr-j  envt  [2]),  and  by  structural  induction  hypothesis,  it  holds. 


□ 

The  above  lemma  says  that  all  possible  monomorphic  instances  of  a  polymorphic  function 
are  related  with  respect  to  the  order-of-demand  property  of  all  occurrences  of  their  param¬ 
eters  and  local  objects.  Based  on  this  fact,  we  prove  that  both  the  global  and  local  before 
analyses  are  polymorphically  invariant. 

Theorem  6.7  (Global  Before  Analysis)  Let  f  be  a  polymorphic  function  of  arity  n, 
and  let  f  and  f"  be  any  two  monomorphic  instances  of  f .  Assume  that  env'  and  env" 
are  abstract  before  escape  semantic  environments  that  map  f  and  f"  to  elements  of  Dt, 
respectively.  Then,  for  X  and  Y , 

G_before?(//,  X ,  Y,  env')  =  G_before? ( /",  X ,  Y ,  env") 

Proof  :  Let  f'a  and  f"  be  the  auxiliary  functions  for  f  and  f" .  respectively.  From  the 
definition  of  the  global  before  test  function, 

G_before?(//,  X,  Y,  env1)  =  (Te[/'  ®n  ...  yn)] env'[f'a  f' a,xi}  h-  .(/i;  J)(i). 

Then,  by  the  definition  of  l\  . 

G_before?(//,  X,  Y,  env1)  =  (NAPm{  (/',  y[u . . . ,  y'no{n)))^) 

where  m  =  £4o(i),  f  =  fe{f'Jenv /'  =  f^f'Jenv'lf  h-  /'],  for  each  xi3  G  A  ,  yL  = 
(2 ,WT>),  for  each  Xij  G  V  .  y[-  =  (0 ,WT>),  and  for  each  Xij  $  X  U  Y,  y[-  =  (1,WT*'). 
Similarly, 
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G_before?(/",  X,  Y,  env”)  =  (NAPm(/",  y'fi. y"o(n)))(i) 

where  f"  -  Te[f"]env",  f”  =  fe{f”Jenv"[f"  h->  /"],  for  each  Xij  G  X,  y”}  =  (2 ,WT"),  for 
each  G  Y ,  y”j  =  (0,fYT*”),  and  for  each  rjj  $  X  U  Y,  y”j  =  (1  ,WT'').  By  Lemma  6.4, 
/'  rJr-j  f"  and  thus  /'  ~~  /".  By  the  definition  of  the  worst-case  escape  function  W, 
y-j  rJr-j  yd. .  Then,  by  the  definition  of  we  have  that 

NAPm(  /',  3/ii,  ■  ■ •!//,.,,( «) )( i )  =  NAPm(/",  . . . ,  <ofn))(i). 

Thus,  we  conclude  that 

G_before?(//,  X ,  Y,  eni)')  =  G_before?  ( f",  X,  Y,  env”) 

□ 

Theorem  6.8  (Local  Before  Analysis)  Let  f  be  a  polymorphic  function  of  arity  n  in 
an  application  f  e i  ...  en.  Let  f  and  f”  be  any  two  monomorphic  instances  of  f ,  and  e( 
and  e”  be  two  monomorphic  instances  of  .  Assume  that  env1  and  env”  are  abstract  escape 
semantic  environments  that  map  f  and  all  free  identifiers  within  e\,  and  f”  and  all  free 
identifiers  within  e”  to  elements  of  Dt,  respectively.  Then,  for  X  and  Y, 

L .before? ( /',  A',  Y,  e[, . . . ,  e'n,  env1)  =  L_before? ( /",  A',  Y,  e", . . . ,  e",  env”) 

Proof  :  This  can  be  proved  in  a  similar  way  to  the  polymorphic  invariance  proof  of  the 
global  before  analysis.  □ 

6.4  Analysis  of  Polymorphic  Languages 

The  type  variables  appearing  in  the  type  of  a  lambda-bound  identifier,  called  non-generic 
type  variables,  are  shared  in  every  occurrence  of  the  identifier  in  the  function  body,  and 
cannot  be  instantiated  to  different  types  in  the  same  expression.  However,  the  type  variables 
which  occur  in  the  type  of  a  letrec-bound  identifier,  called  generic  type  variables,  can  be 
instantiated  to  different  types  in  the  same  expression.  Since  the  letrec-bound  identifier  is 
local  to  the  expression,  we  know  exactly  how  it  is  defined  and  can  use  this  information  to 
deal  with  each  of  its  occurrences  individually. 

In  proving  the  polymorphic  invariance  of  the  semantic  analysis,  we  treated  a  poly¬ 
morphic  expression  as  the  set  of  its  possible  monomorphic  instances.  In  this  section,  we 
describe  the  semantic  analysis  of  a  higher-order  functional  language  with  a  polymorphic 
type  system  which  allows  generic  (parametric)  polymorphism,  and  all  type  variables  are 
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universally  quantified  at  the  top  level.  Furthermore,  quantifiers  can  not  be  nested  inside 
type  expression,  called  shallow  types.  Occurrences  of  the  same  generic  letrec-bound  iden¬ 
tifier  may  have  different  monotyped-instances.  This  can  be  resolved  by  making  each  of 
differently  monotyped  occurrences  a  distinct  non-generic  identifier.  We  transform  each 
letrec-expression  as  follows: 


letrec 

x1  =  ei ; 

in  e 


letrec 


(i)  _ 


rj  =  6| ;  ...  x1  '  =  ei 


d1)  _ 


m  e 


where  m(i)  is  the  number  of  occurrences  of  27  with  differently  monomorphic  instances  in  the 
expression  e,  and  e'  is  derived  from  e  by  replacing  the  jth  occurrence  of  27  with  differently 
monomorphic  instances  by  xj  for  all  1  <  i  <  n  and  0  <  j  <  m(i). 

As  an  example,  consider  the  polymorphic  function  as  follows: 


f  x  y  z  =  letrec 

len  a  =  if  (null  a)  then  0  else  1  +  len  (cdr  a) ; 

sum  b  =  if  (null  b)  then  0  else  (car  b)  +  sum  (cdr  b) ; 

in 

if  (sum  y)*(len  y)  <  (sum  (car  z))*(len  z) 
then  x  else  (cdr  x) 

The  types  of  functions  f ,  len,  and  sum  are 

f  :  Va.  a  list  — >  ini  list  — >  ini  list  list  — >  a  list 

len  :  V/3.  (3  list  — >  ini 

sum  :  V7.  7  list  — >  int 

Two  occurrences  of  the  letrec-bound  identifier  len  are  instantiated  to  different  types,  i.e. 

The  first  occurrence  of  len  :  V/3.  f3  list  — »  int  [  j3  —  int  ] 

The  second  occurrence  of  len  :  V/3.  (3  list  — ►  int  [  [3  —  int  list  ] 

Thus,  we  transform  the  function  definition  of  f  into  as  follows: 
f  x  y  z  =  letrec 

len’  a  =  if  (null  a)  then  0  else  1  +  len’  (cdr  a); 
len’’  a  =  if  (null  a)  then  0  else  1  +  len’ ’  (cdr  a); 
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sum  b  =  if  (null  b)  then  0  else  (car  b)  +  sum  (cdr  b) ; 
in 

if  (sum  y)*(len’  y)  <  (sum  (car  z))*(len’ ’  z) 
then  x  else  (cdr  x) 

In  order  to  get  some  polymorphically  invariant  information  about  the  polymorphic  function 
f,  we  find  the  simplest  monomorphic  instance  of  f  and  analyze  that  function  using  the 
monomorphic  analysis.  As  a  simplest  monomorphic  instance,  we  let  a  =  int.  Then,  the 
monotypes  of  functions  f ,  len’ ,  len’  ’  and  sum  are 

f  :  int  list  — >  int  list  -+  int  list  list  — >  int  list 

len’  :  int  list  —  int 

len’  ’  :  int  list  list  — ►  int 

sum  :  int  list  int 

Then,  we  apply  the  analysis  for  monomorphic  languages  to  this  transformed  functions. 
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Chapter  7 


Extensions  to  Non-strict 
Languages 


So  far  in  the  previous  chapters  we  have  discussed  a  set  of  escape  analyses  for  higher-order 
functional  languages  with  strict  semantics.  Many  modern  functional  languages,  however, 
adopt  a  non-strict  semantics  and  use  the  lazy  evaluation  model.  These  languages  are  more 
powerful  than  strict  languages  in  expressiveness  but  requires  quite  a  different  kind  of  im¬ 
plementation  model. 

In  this  chapter,  we  extend  the  escape  analysis  and  the  reference  escape  analysis  for  a 
strict  language  to  a  non-strict  language.  First,  we  describe  a  method,  based  on  a  source-to- 
source  transformation  of  non-strict  programs,  to  extend  the  escape  analysis  and  the  reference 
escape  analysis  for  a  strict  language  to  a  non-strict  language  with  normal-order  evaluation 
using  the  analysis  techniques  for  a  strict  language.  The  lazy  evaluation  model  is  identical 
to  the  normal-order  evaluation  model  in  the  standard  semantics,  but  not  in  an  operational 
semantics.  In  lazy  evaluation,  arguments  to  a  function  are  not  evaluated  unless  and  until 
their  values  are  demanded,  and  are  evaluated  only  once  upon  the  first  demand.  Their  values 
are  then  saved  to  be  used  for  subsequent  demands,  thus  avoiding  reevaluation.  Using  the 
order-of-demand  analysis  described  in  Chapter  5,  we  extend  the  escape  and  reference  escape 
analyses  to  non-strict  functional  languages  using  lazy  evaluation.  Finally,  the  extension  for 
a  non-strict  language  using  optimized  lazy  evaluation  based  on  the  strictness  information 
is  discussed. 
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7.1  Escapement  under  Normal-Order  Evaluation 

Two  methods  are  used  for  implementing  non-strict  semantics:  either  a  normal-order  (call- 
by-name)  evaluation  or  a  lazy  (call-by-need)  evaluation.  In  a  non-strict  semantics  with 
normal  order  evaluation,  all  arguments  to  a  function  are  passed  to  the  function  in  an 
unevaluated  form  and  are  only  evaluated  whenever  needed  inside  the  function  call.  In  order 
to  achieve  normal  order  evaluation,  the  following  two  mechanisms  are  required: 

1.  A  mechanism  to  delay  or  suspend  the  evaluation  of  expressions  when  their  evaluated 
values  are  not  needed  immediately; (for  example,  when  expressions  are  passed  to  some 
non-strict  function.) 

2.  A  mechanism  to  force  the  evaluation  of  suspended  expressions  when  their  values  are 
needed;  (for  example,  when  they  are  passed  to  some  strict  function.) 

On  a  conventional  machine,  normal-order  evaluation  is  effected  by  creating  a  closure,  called 
thunk,  consisting  of  some  code  along  with  bindings  for  its  free  variables,  to  represent  a  de¬ 
layed  expression.  These  thunks  must  generally  be  allocated  in  the  heap  and  their  evaluation 
requires  a  function  call  to  force  the  evaluation. 

In  general,  we  can  simulate  a  non-strict  language  using  a  strict  language  by  the  intro¬ 
duction  of  explicit  delays  and  forces.  A  way  to  simulate  normal-order  evaluation  is  to  insert 
some  code  to  delay  the  evaluation  of  any  expression  which  will  not  be  immediately  needed, 
including  all  arguments  passed  to  user-defined  functions,  and  to  insert  appropriate  code  to 
force  the  evaluation  of  the  delayed  expression  when  they  are  needed.  It  is  possible  to  repre¬ 
sent  delayed  expressions  by  using  the  same  closures  which  are  used  for  representing  function 
values.  Given  an  argument  expression  e,  we  can  use  beta-abstraction  to  translate  e  into  the 
expression  ( Xx.e)  y  for  any  y  provided  neither  x  nor  y  occur  free  in  e.  For  convenience,  we 
define  as  follows: 

•  ()  denotes  a  void  identifier 

•  []  denotes  a  dummy  expression. 

Then  we  can  write  this  as  (AQ.e)  []  without  having  to  worry  about  naming  problem.  When¬ 
ever  the  value  of  e  is  required,  we  have  to  explicitly  force  the  evaluation  of  e.  To  do  this,  we 
have  to  apply  the  closure  for  e  to  a  dummy  argument.  This  forcing  is  only  required  to  be 
done  when  the  value  of  the  expression  is  actually  needed.  The  delay  and  force  operations 
can  be  implemented  by  a  strict  language  as  follows: 
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DELAY  exp  =  lambdaQ .  exp  /*  create  delayed  expression  */ 


FORCE  delayed. exp  =  (delayed.exp  [] )  /*  evaluation  */ 


Thus,  in  general,  any  non-strict  language  can  be  simulated  by  a  strict  language  through  a 
source-to-source  transformation  of  non-strict  programs  into  their  strict  counterparts. 

Since  the  operational  semantics  of  a  strict  language  is  not  equivalent  to  that  of  its  non- 
strict  counterpart,  the  escapement  under  non-strict  semantics  with  normal-order  evaluation 
becomes  different  from  the  escapement  under  strict  semantics.  As  an  example,  consider  the 
following  non-strict  (using  normal-order  evaluation)  program: 

letrec  f  x  y  =  x+y; 

g  a  =  if  (a=0)  then  (f  a)  else  (f  3) ; 
h  c  d  =  g  (c+d) ; 

in  ... 

Consider  the  escapement  of  the  parameters  c  and  d  from  the  function  h.  In  a  strict  language, 
during  the  execution  of  h’s  body,  the  expression  (c+d)  will  be  evaluated  before  g  is  applied 
to  it,  and  therefore  neither  c  or  d  escape  from  h.  However,  in  a  non-strict  language,  during 
the  execution  of  h’s  body,  a  closure  representing  the  delayed  expression  (c+d)  will  be  created 
and  passed  to  g.  During  the  execution  of  g’s  body,  the  closure  is  passed  to  f  and  thus  both 
c  and  d  may  escape  from  h  within  the  closure  representing  the  partial  application  of  f . 

Consider  the  escapement  of  references  associated  with  occurrences  of  the  parameters  c 
and  d  from  their  function  h.  When  h  is  called,  its  activation  record  contains  two  references, 
corresponding  to  the  parameters  c  and  d,  to  the  actual  arguments.  The  actual  param¬ 
eters  are  themselves  closures.  During  the  evaluation  of  the  body  of  h,  when  (g  (c+d)) 
is  evaluated,  a  closure  is  created  for  (c+d).  The  references  corresponding  to  c  and  d  are 
copied  into  the  closure.  Then,  the  reference  to  this  closure  is  copied  into  the  activation 
record  for  g.  During  the  execution  of  g’s  body,  this  reference  is  passed  to  f  and  thus  both 
references  associated  with  c  and  d  may  escape  from  h  within  the  closure  representing  the 
partial  application  of  f . 

Property  7.1  (Non-strict  Escape  Property)  In  the  normal-order  evaluation  model, 
given  an  expression  exp ,  the  escape  semantic  value  of  exp  when  its  evaluation  is  delayed, 
has  the  following  properties: 
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•  The  first  component  of  the  escape  semantic  value  of  exp  is  the  least  upper  bound  of 
the  first  components  of  the  escape  semantic  values  of  all  identifiers  in  ex p,  because 
when  exp  is  eventually  evaluated,  the  values  of  all  identifiers  in  exp  will  be  needed. 

•  The  second  component  of  the  escape  semantic  value  of  exp  is  er  r  because  the  delayed 
exp  itself  is  not  a  function  type  and  thus  it  can  not  be  applied  directly  to  any  argument. 

•  The  escape  semantic  value  of  exp  must  be  retained  somehow  in  order  to  represent  the 
escape  semantic  value  when  exp  is  evaluated. 

7.1.1  Program  Transformation 

Thus,  the  escape  analysis  and  the  reference  escape  analysis  for  a  non-strict  functional  lan¬ 
guage  can  be  achieved  by  first  transforming  non-strict  programs  into  equivalent  strict  pro¬ 
grams  and  then  by  applying  the  analyses  to  the  transformed  programs.  The  source-to-source 
transformation  function  N  of  type  Exp  —  Powerset(  Id)  — ■>  Exp  for  non-strict  programs  is 
defined  in  Figure  7.1. 

7.1.2  Using  Escape  Analysis  for  Strict  Languages 

The  abstract  escape  semantic  function  Oc  for  a  dummy  expression  []  is  defined  as  follows: 
OM  =  (0,  err) 

Global  Non-strict  Escape  Test 

We  describe  a  global  escape  test  for  non-strict  functions.  Given  a  non-strict  function 
f  x i  X2  ...  xn  =  bodyj  of  arity  n,  the  position  i  of  an  interesting  parameter,  and  an 
abstract  escape  semantic  environment  env0  mapping  a  transformed  version  of  /  to  an  ele¬ 
ment  of  D0 ,  the  global  non-strict  escape  test  function  G_n_escape?  determines  whether  the 
ith  parameter  of  the  non-strict  function  /  could  possibly  escape  /  globally  or  not.  It  is 
defined  as  follows: 

G_n_escape?( /,  i,  env0)  =  (Oe[/'  x1  . . .  xnJ  env0[xi 
where  f  is  a  transformed  version  of  /, 

Vi  =  (l  ,A().<1,IW‘», 

for  all  j  <  n  and  j  i, 

Vj  =  (0,  A().(0,WTi)), 
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N[c]  Fid  =>  A().c 

N[a]  Fid  =>  if  (a  G  Fid)  then  a  else  (a  [] ) 

N[ex  +  e2]  Fid  =>  (N[ca]  Fid)  +  (N[e2]  Fid) 

/*  same  for  strict  operators  like  (cj  —  £2)  and  (ei  =  e2)  */ 
N[if  ej  then  e2  else  e3]  Fid  =>•  if  (Nflei]  Fid) 

then  (N[e2]  Fid) 
else  (N[e3]  Fid) 

N[eie2]  Fid  =>  if  fix  G  {  car,  cdr  } 

then  /*  strict  operator  */ 

(N [e^FId)  (N[e2]  Fid) 
else  /*  non-strict  operator  */ 

(N[ei]  Fid)  (A().N[e2]  Fid) 

N[lambda(a).e]  Fid  lambda(a).(N[e]  Fid) 

N|letrec  xi  =  e1; . .  ,xn  =  en;  in  e]  Fid  =>  letrec 

x1  =  N[ei]  ( Fid  U  {ax,- . . . ,  a„}); 


Np[pr]  =>•  N  {pr}  0 


xn  —  (Fid  U  {ai, . . . ,  an}), 

in 

N[ex]  (Fid  U  {ax, . .  .,a„}) 


Figure  7.1:  Non-strict  Program  Transformation 


145 


and  Tj  is  the  type  of  the  ith  parameter  of  /.  Then,  from  the  result  of  the  global  non-strict 
escape  test  function,  we  can  conclude  as  follows: 

•  If  G_n_escape?(/,  i,  env0)  =  0  then  we  conclude  that  in  any  possible  application  of  a 
non-strict  /  to  n  arguments,  the  ith  delayed  argument  does  not  escape  /. 

•  If  G_n_escape?  ( /,  i.  ehv0)  =  1  then  it  means  that  the  ith  delayed  argument  could  escape 
/  in  some  possible  application  of  a  non-strict  /  to  n. 

Local  Non-strict  Escape  Test 

We  describe  a  local  escape  test  for  non-strict  functions  in  a  particular  context.  Given  a  non- 
strict  function  f  x  i  x2  ■  ■  ■  xn  =  bodyj  of  arity  n  in  an  application  /  e%  ...  en ,  the  position 
i  of  an  interesting  parameter,  and  an  abstract  escape  semantic  environment  env0  mapping 
a  transformed  version  of  /  and  the  free  identifiers  within  ej  through  en  to  elements  of  D0, 
the  local  non-strict  escape  test  function  L_n .escape?  determines  whether  the  ith  parameter 
of  the  non-strict  function  /  could  escape  /  during  the  evaluation  of  /  e\  ...  e„.  It  is  defined 
as  follows: 

L_n _escape?(  /,  Ldi,  •  •  • ,  fn,  tnv0 )  =  (<9e[ /'  x1  . . .  xn\  env0[xi  h->  </;])(,) 
where  f  is  the  transformed  version  of  /, 

Vi  =  (1,  A().(l,(6e[ej]  env0){2)}), 
and  for  all  j  <  n  and  ;j  /  1. 

yj,  =  <0,A().<0,(6e[ej]  eh%)(2))). 

Then,  from  the  result  of  the  local  non-strict  escape  test  function,  we  can  conclude  the 
following: 

•  If  L_n_escape?(/,  i,  ej-, . . . ,  e„,  env0)  =  0  then  we  conclude  that  the  ith  delayed  argu¬ 
ment  does  not  escape  /  locally  in  the  particular  application  of  /  to  e\  through  en. 

•  If  L_n_escape?(  /,  i,  ej, . . .  ,en,ehv0)  =  1  then  it  means  that  the  ith  delayed  argument 
could  escape  /  locally  in  the  particular  application  of  /  to  ei  through  en. 

7.1.3  Using  Reference  Escape  Analysis  for  Strict  Languages 

The  abstract  reference  escape  semantic  function  Rc  for  a  dummy  expression  []  is  defined 
as  follows: 

KtM  =  ((0,0),  err) 
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Global  Non-strict  Reference  Escape  Test 

Given  a  non-strict  function  f  x  1X2  . . .  xn  =  bodyj  of  arity  n.  the  position  ( i,j )  of  an  in¬ 
teresting  occurrence  of  a  parameter,  and  an  abstract  reference  escape  semantic  environment 
envr  mapping  the  auxiliary  function  of  the  transformed  version  of  /  to  an  element  of  Dr, 
the  global  non-strict  reference  escape  test  function  G_n_refescape?  determines  whether  the 
reference  associated  with  the  jth  occurrence  of  the  ith  parameter  of  the  non-strict  function 
/  could  escape  /  globally.  It  is  defined  as  follows: 

G_n_refescape? (/,  i.  j.  ehvr)  = 

(Relf”  x1  ...  zlo(1)  ...  xn  ...  xrio(l0J  envr[f"  >->  J".  xijt  ^ 
where  f"  is  an  auxiliary  function  for  f  is  a  transformed  function  of  /, 
f"  =  Relfjenvr, 

.  <{1.0),  A().«1.0).11'0), 

for  all  k  <  o(i )  and  k  7^  j, 

Vik  =  «0,  0),  A(  ).«0,  0),  IT7*)), 
for  all  1  <  m  <  o(l)  and  l  7^  i. 

Uhri  -  {(()•());  A(). {{().()).  11 

and  Tj  is  the  type  of  the  ith  parameter  of  /.  Then,  from  the  result  of  the  global  non-strict 
reference  escape  test  function,  we  can  conclude  as  follows: 

•  If  G_n_refescape?(/,  i,j,  ehvr)  =  0  then  we  conclude  that  in  any  possible  application  of 
a  non-strict  function  /  to  n  arguments,  the  reference  associated  with  the  jth  occurrence 
of  the  ith  delayed  argument  does  not  escape  /. 

•  If  G_n_refescape?(/,  i,j,  envr)  =  1  then  it  means  that  in  some  possible  application  of  a 
non-strict  function  /  to  n  arguments,  the  reference  associated  with  the  jth  occurrence 
of  the  ith  delayed  argument  could  escape  /. 

Local  Non-strict  Reference  Escape  Test 

Given  a  non-strict  function  f  xi  x 2  ■■■  xn  =  bodyj  of  arity  n  in  a  particular  function 
application  f  e  1  ...  en,  the  position  (i,j)  of  an  interesting  occurrence  of  a  parameter,  and 
an  abstract  reference  escape  semantic  environment  ehvr  mapping  the  auxiliary  function  for 


147 


the  transformed  version  of  /  and  the  free  identifiers  within  e.j.  through  en  to  elements  of  Dr , 
the  global  non-strict  reference  escape  test  function  L_n_refescape?  determines  whether  the 
reference  associated  with  the  jth  occurrence  of  the  ith  parameter  of  the  non-strict  function 
/  could  escape  /  in  the  evaluation  of  /  ...  e„.  It  is  defined  as  follows: 

L_n_refescape?(/,  i,j ,  ei, ...  ,en,  ehvr)  = 

(Al/"  ■  ■  ■  £i0(i)  ...  xn  ...  xno{n)\  envr[f "  h->  /",  Xij  ^  2/ii])(i)(i) 

where  /"  is  an  auxiliary  function  for  [' .  f  is  a  transformed  function  of  /, 
f"  =  Relf}envr, 

Vij  =  «1,0),A( ).((!,  0),(AN]ehnr)(2))), 
for  all  k  <  o(i )  and  k  /  j . 

Vik  =  «0,0),A().«0,0),(A[e4]ennr)(2))), 

and  for  all  1  <  m  <  o(l )  and  l  7^  i. 

Vim  =  «0,0),  A().<<0,0),(A[e;]ehnr)(2))). 

Then,  from  the  result  of  the  local  non-strict  reference  escape  test  function,  we  can  conclude 
the  following: 

•  If  L_n_refescape?(/,  i,  j,  ei, . . . ,  e„,  envT)  =  0  then  we  conclude  that  the  reference  as¬ 
sociated  with  the  jth  occurrence  of  the  ith  delayed  argument  does  not  escape  /  in 
(/  ej  ...  en). 

•  If  L_n_refescape?(  /,  i,  j,  ei, . . . ,  en,  envr)  =  1  then  it  means  that  the  reference  associ¬ 
ated  with  the  jth  occurrence  of  the  ith  delayed  argument  could  escape  /  in  (/  e\  ...  en  ). 

7.1.4  Examples 

As  an  example,  consider  the  following  non-strict  program: 

letrec  f  x  y  =  x+y; 

g  a  =  if  (a=0)  then  (f  a)  else  (f  3) ; 
h  c  d  =  g  (c+d) ; 

in  ... 

where  f ,  g,  h  :  int  int  — *■  int.  The  transformed  functions  f  ’ ,  g'  and  h’  for  f,  g  and  h, 

based  on  the  program  transform  function  N,  are  defined  as  follows: 


148 


letrec  f’  x  y  =  (x  [] )  +  (y  []); 

g’  a  =  if  ((a  [] )  =0)  then  (f  ’  lambdaQ  .  (a  [])) 
else  (f’  lambdaQ  . 3) ; 
h’  c  d  =  g’  lambdaQ.  ((c  [] )  +  (d  [])); 

in  ... 

where  f 1  ,  g’ ,  h’  :  (*  — >  ini )  — >  (*  — >  ini )  — >  (*  — *■  ini)  and  *  denotes  the  type  of  a  void 
identifier  and  a  dummy  expression. 

Non-strict  Escape  Information 

The  definitions  of  the  escape  semantic  values  f,  (j1 .  and  h'  off’,  g’,  and  h’  are  expressed 
as  follows: 

/'  =  (0,  Xx.(x^,  Xy.(0,  err))) 

g'  =  (0,Ao.(/('2)  (a(1),A().o(0,err))U(/'2)  (0,  A().(0,  err)))) 

=  (0,  A a.(/'2)  A().a  (0,  err))) 

ti  =  (0,  Ac.(cfl),  Xd.gfa  ((c(1)  U  d(1)),  A().(0,  err)))) 

Let  env0  =  [f  ’  i-»  /',  g’  h- ■  g1,  h’  >->  h']. 

To  find  the  global  escape  property  of  the  non-strict  function  h,  we  apply  the  non-strict 
global  escape  test  function  G_n .escape?  as  follows: 

G_n_escape?(h,  1,  ehv0)  =  (Oe[h’  c  dJejirQ^j 

=  1 

where 

env'o  =  env0[ c  n-  (1,  A().(l,  d  (0,  A().(0, 

and 

=  Xx.(x(1),Xy.x(1)  U  2/(1),  err)). 

Then,  we  can  conclude  that  the  first  parameter  c  of  the  function  h  could  escape  h  globally. 
Similarly, 

G_n_escape?(h,  2,  ehv0)  =  (Oe[h’  c  djem^)^) 

=  1 

where 

env'0  =  env0[c  ^  (0,  A().(0,  (•—*«*))),  d  h->  (1,  A().(l, 
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and 


_  Xx.(x^,  Xy.x^  U  err)). 

Thus,  we  can  conclude  that  the  second  parameter  d  of  the  function  h  could  also  escape  h. 

Non-strict  Reference  Escape  Information 

The  definitions  of  the  reference  escape  semantic  values  f .  g',  and  h'  of  f  ’,  g  ’ .  and  h  ’  are 
expressed  as  follows: 

/'  =  ((0,0),  Ar.(rfl),  Ay.((0,  0),  err))) 

g'  =  ((0,0),Au.(/'2)  (opj,  A().a  ((0,  0),  err))  U  (/'2)  ((0,  0),  A(  ).((0, 0),  err)))) 

=  ((0,0),  Aa.(/('2)  («(!),  A().a  ((0,  0),  err))) 

b!  =  ((0,0),  Ac.(c(1),  Xd.g'{2)  ((c(1)  U  d(1)),  A().((0, 0),  err)))) 

The  auxiliary  functions  f  ’  ’ ,  g’  ’  and  h  ’  ’  for  the  transformed  functions  f  ’ ,  g’  and  h  ’  are 
defined  as  follows: 

f”  x  y  =  (x  [])  +  (y  []); 

g'  al  a2  =  if  ((al  [] )  =0)  then  (f’  lambdaO .  (a2  [])) 
else  (f’  lambdaO. 3); 
h’  c  d  =  g’  lambdaO.  ((c  □ )  +  (d  [])); 

Then,  the  definitions  of  reference  escape  semantic  values  /",  g",  and  h"  of  f  ’  ’ ,  g’  ’ ,  and 
h’  ’  are  expressed  as  follows: 

I"  =  ((0,  0),  Aar.(a:(1),  Xy. ((0,0),  err))) 

g"  =  ((0,  0),  Aal.(al(1),  Aa2.(/'2)  (a2(1),  AQ.a2(2)  ((0,  0),  err))) 
h"  =  ((0,  0),  Ac.(c(1),  A d.g'{2)  ((c(1)  U  d(1)),  A().((0, 0),  err)))) 

Let  envr  =  [f  ’  f  ’  ’  i->  g ’  >-*  g',g’  ’  i-»  g",h’  i-»  h',h’  ’  h"]. 

To  find  the  global  reference  escape  property  of  the  non-strict  function  h,  we  apply  the 
non-strict  global  reference  escape  test  function  G_n_refescape?  as  follows: 

G_n_refescape?(h,  1, 1, envT)  =  (Re |h’ ’  c  d]euu/7.)(1((1( 

=  1 

where 

env'T  -  envr[c  ^  ((1,  0),  A().((l,  0),  *«*)-*(*— *«0))^ 

d  i  ^  ((0, 0),  A().((0, 0),  ««*)) )] 
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Then,  we  can  conclude  that  the  reference  associated  with  the  first  occurrence  of  the  first 
parameter  c  of  the  function  h  could  escape  h  globally.  Similarly, 

G_n_refescape?(h,  2, 1,  ehvT)  =  (_Re[h’ ’  c  d]enn,7.)(i)(i) 

=  1 

where 

env'r  =  efivr[ c  <<0,  0),  AQ.«0, 0), 

d  ^  ((1,  0),  A().«1,0),  VT(*-**"*)— ’(*-**"*)> ) ] 

Thus,  we  can  conclude  that  the  reference  associated  with  the  first  occurrence  of  the  second 
parameter  d  of  the  function  h  could  also  escape  h. 

7.2  Escapement  under  Lazy  Evaluation 

The  demand-driven  evaluation  of  an  expression  in  a  non-strict  language  is  effected  by  creat¬ 
ing  some  delayed  representation  which  contains  enough  information  to  enable  the  expression 
to  be  evaluated  later  when  needed.  In  particular,  this  requires  some  mechanism  for  creating 
the  delayed  expression  and  some  mechanism  for  forcing  its  evaluation.  A  naive  imple¬ 
mentation  of  normal-order  reduction  would  result  in  an  implementation  in  which  actual 
parameters  were  copied  as  they  were  bounded  to  formal  parameters  in  function  applica¬ 
tion.  Using  this  strategy,  an  argument  could  be  evaluated  several  different  times,  resulting 
in  some  inefficiency.  The  lazy  evaluation  model  is  an  efficient  implementation  method  in 
which  each  argument  is  computed  at  most  once.  In  a  non-strict  semantics  using  lazy  eval¬ 
uation,  all  arguments  to  a  function  are  passed  to  the  function  in  an  unevaluated  form  and 
are  evaluated  only  once  when  first  needed  inside  the  function  call.  Thus,  in  lazy  evaluation, 
some  other  mechanism  is  needed  to  avoid  the  recomputation  of  a  value.  In  addition,  the 
representation  of  the  delayed  expression  must  contain  the  code  to  be  evaluated  and  the  en¬ 
vironment  in  which  to  evaluate  the  code.  In  order  to  elfect  the  lazy  evaluation,  we  basically 
require  the  following  three  mechanisms: 

1.  A  mechanism  to  delay  or  suspend  the  evaluation  of  expressions  when  their  evaluated 
values  are  not  needed  immediately; (for  example,  when  expressions  are  passed  to  some 
non-strict  function.) 

2.  A  mechanism  to  force  the  evaluation  of  evaluation-suspended  expressions  when  the 
evaluated  values  of  evaluation-suspended  expressions  are  needed;  (for  example,  when 
they  are  passed  to  some  strict  function.) 
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3.  A  mechanism  to  avoid  the  re-evaluation  of  suspended  expressions  when  their  values 
are  needed  and  their  evaluations  have  already  been  forced. 

On  a  conventional  machine,  lazy  evaluation  is  effected  by  creating  a  run-time  structure, 
called  self-modifying  thunk ,  consisting  of  some  code  along  with  bindings  for  its  free  vari¬ 
ables,  the  status  of  the  evaluation  and  the  value  when  already  evaluated,  to  represent  a 
delayed  expression.  These  self-modifying  thunks  must  generally  be  allocated  in  the  heap 
and  their  evaluation  requires  a  test  of  the  evaluation  status,  a  function  call  to  force  the 
evaluation,  and  an  update  with  the  evaluated  value.  Due  to  the  absence  of  side  effects 
of  functional  languages,  lazy  evaluation  is  equivalent  to  normal-order  reduction  under  the 
standard  semantics,  but  it  is  often  more  efficient  since  it  requires  no  recomputation.  We 
can  not  implement  a  lazy  evaluation  model  using  a  strict  pure  functional  language  because 
we  cannot  explicitly  overwrite  the  environment.  Lazy  evaluation  can  be  implemented  only 
through  the  use  of  side-effects.  One  way  of  implementing  the  lazy  evaluation  model  is  as 
follows: 

DELAY  exp  =  lambdaQ .  exp  /*  create  delayed  expression  */ 

FORCE  delayed. exp  =  if  already.evaluated? (delayed.exp) 

then  return  V;  /*  no  evaluation  */ 
else  V  :=  (delayed.exp  [] ) ;  /*  evaluation  */ 

save  V  in  some  place; 
return  V ; 


The  escapement  under  a  non-strict  semantics  with  lazy  evaluation  is  not  equivalent  to 
the  escapement  under  a  non-strict  semantics  with  normal-order  evaluation,  because  their 
operational  semantics  are  different.  Consider  the  following  program  as  before  but  with  lazy 
evaluation: 

letrec  f  x  y  =  x+y; 

g  a  =  if  (a=0)  then  (f  a)  else  (f  3) ; 
h  c  d  =  g  (c+d) ; 

in  ... 

Consider  the  escapement  of  the  parameters  c  and  d  from  their  function  h.  As  described 
before,  in  a  non-strict  language  with  normal-order  evaluation,  a  closure  representing  the 
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delayed  expression  of  (c+d)  will  be  created  and  passed  to  g  during  the  execution  of  h’s 
body.  During  the  execution  of  g’s  body,  this  closure  is  passed  to  f  and  thus  both  c  and  d 
may  escape  from  h  within  the  closure  representing  the  partial  application  of  f .  However, 
in  a  non-strict  language  with  lazy  evaluation,  a  closure  representing  the  delayed  expression 
of  (c+d)  will  be  created  and  passed  to  g  during  execution  of  h’s  body.  In  the  execution  of 
g,  the  delayed  expression  of  (c+d)  is  forced  to  be  evaluated  during  the  evaluation  of  (a=0) 
and  thus  neither  c  and  nor  d  will  escape  h. 

Consider  the  escapement  of  references  associated  with  occurrences  of  the  parameters 
c  and  d  from  their  function  h.  When  h  is  called,  its  activation  record  contains  two  ref¬ 
erences,  corresponding  to  the  parameters  c  and  d,  to  actual  parameters  which  are  self¬ 
modifying  thunks.  During  the  evaluation  of  the  body  of  h,  when  (g  (c+d))  is  evaluated,  a 
self-modifying  thunk  is  created  for  the  delayed  evaluation  of  (c+d).  The  references  corre¬ 
sponding  to  c  and  d  are  copied  into  the  self- modifying  thunk.  Then,  the  reference  to  this 
self-modifying  thunk  is  copied  into  the  activation  record  for  g.  During  the  execution  of 
g’s  body,  this  self-modifying  thunk  is  actually  evaluated  via  (a=0)  and  the  result  value  is 
saved  in  the  self- modifying  thunk  for  later  demand.  When  the  value  of  this  self-modifying 
thunk  is  demanded  in  future,  the  value  saved  is  just  returned  without  further  evaluation. 
Thus,  even  if  this  self- modifying  thunk  is  passed  to  f  in  the  partial  application  to  f ,  both 
references  associated  with  c  and  d,  which  are  contained  in  the  self-modifying  thunk,  do  not 
escape  from  h  because  they  are  no  longer  needed. 

Property  7.2  (Lazy  Escape  Property)  In  the  lazy  evaluation  model,  given  an  expres¬ 
sion  exp ,  the  escape  semantic  value  of  exp  when  its  evaluation  is  delayed,  has  the  following 
properties: 

•  The  first  component  of  the  escape  semantic  value  of  exp  is  the  least  upper  bound  of 

1.  the  least  upper  bound  of  the  first  components  of  the  escape  semantic  values  of 
all  identifiers  in  exp  that  have  not  yet  been  evaluated. 

2.  the  least  upper  bound  of  the  first  components  of  the  escape  semantic  values 
of  all  identifiers  in  exp  that  have  been  already  evaluated,  because  when  exp  is 
eventually  evaluated  the  values  of  all  identifiers  in  exp  are  needed. 

•  The  second  component  of  the  escape  semantic  value  of  exp  is  err  because  exp  itself  is 
not  a  function  type  and  thus  it  can  not  be  applied  directly  to  any  argument. 

•  The  escape  semantic  value  of  exp  must  be  retained  somehow  in  order  to  represent  the 
escape  semantic  value  when  exp  is  evaluated. 
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Thus,  information  about  evaluation  status  is  useful  for  the  escape  analysis  and  the  reference 
escape  analysis  of  a  non-strict  functional  language  with  lazy  evaluation. 

7.2.1  Using  Status-of-Evaluation  Information 

Information  on  the  evaluation  status  of  arguments  to  a  function  when  they  are  demanded  is 
useful  for  describing  the  escapement  behavior  under  lazy  evaluation.  Given  an  occurrence 
xt  of  a  variable  x  in  the  body  of  a  function  /,  if  there  exists  another  occurrence  Xj  of  x 
such  that  xj  is  demanded  before  X{  in  each  possible  execution  of  the  body  of  /  then  we  say 
that  Xi  has  an  evaluated  status.  This  means  that  x  must  already  have  been  evaluated  by 
the  time  xt  is  encountered.  Information  about  the  evaluated  status  of  an  occurrence  of  a 
parameter  of  a  function  can  be  inferred  at  compile-time  using  the  order-of-demand  analysis 
described  in  Chapter  5. 

For  example,  consider  the  following  function: 

g  a  =  if  (a=0)  then  (f  a)  else  (f  3) ; 

Let  the  two  occurrences  of  the  parameter  a  in  the  body  of  the  function  g  be  a’  and  a’  ’ 
from  left-to-right,  respectively.  The  occurrence  aJ  ’  has  an  evaluated  status,  because  the 
argument  a  is  evaluated  before  it  is  demanded  via  a’  ’  due  to  the  demand  via  the  occurrence 

a’ . 

7.2.2  Escape  Analysis  for  Lazy  Evaluation 

The  abstract  escape  semantic  domain  D0  (an  abstraction  of  D0),  and  the  domain  E0  of 
abstract  escape  environments  are  defined  as  follows: 


Do  = 

E 

bT0 

/*  Abstract 

escape  semantic  domain  */ 

D0  = 

id 

-  Dq 

/*  Domain  of  abstract  escape  environments  */ 

f)int 

= 

B0  x 

{err} 

abstract  subdomain  for  integers 

jSbool 

= 

B0  x 

{err} 

abstract  subdomain  for  booleans 

DTo^n 

= 

B0  x 

( b ?  -  bin 

abstract  subdomain  for  functions 

nr i  list 
^  0 

= 

D7 

abstract  subdomain  for  lists 

The  abstract  escape  semantic  functions  are  as  follows: 

Oc  ■  Con  — »  D0  /*  Abstract  escape  semantic  function  for  constants  */ 

Oe  ■  Exp  — >  E0  — ►  D0  /*  Abstract  escape  semantic  function  for  expressions  */ 

Opr  :  Program  —  D0  /*  Abstract  escape  semantic  function  for  programs  */ 
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Oc[Q]  =  <0, err) 

Oc[c]  =  (0  ,err),  c  £  {•••,  —  i,  0, 1, true,  false} 

Oc[nilr /4st]  =  ±T  (The  bottom  element  of  D0.) 

Oc[cons]  =  (0,  Xx.{x^,  Xy.x  U  y)) 

Oc[car]  =  (0,\x.x) 

Oc[cdr]  =  (0,\x.x) 

Oc|null]  =  (0,  Aa\(0,  err)) 

Oe{c^ehv0  =  Oc{cJ 

Oe{xjenv0  =  env0{xj 

Oe [ei  +  e2 Jenv0  =  (0 ,err)  /*  same  for  e\  —  e2  and  ei  =  e2  */ 

Oe[if  e3  then  e2  else  e3jenv0  =  (Oe|ei]efit70)  U  (Oele2}env0) 
Oe|eie2]ent;0  =  (Oe[e1]ent;0)( 2)  (Oele2Jenv0) 

Oe[lambda(a-).e]efir>0  =  (V",  \y  .0  e\e\ehv  0[x  hh>  y]) 

where 

V  =  0  u  (  |J  (f  hr,.[.:J)(i))  U  (  [_|  (Oe{  (z  [])  ]eht)0)(1)), 

z£]7 _ Jpeval  g£]?eval 

F  =  Set  of  free  identifiers  in  (lambda(a).e),  and 
jpeval  _  ge|  q£  £ree  identifiers  with  an  evaluated  status. 

Oe[letrec  x\  =  e\\ . . .  xn  =  en;  in  ejehv0  =  Oe\_e\ehv'0 

where  env'0  =  ehv0[x1  h->  Oe[ei]era*^3  Oe[e„]ent>^] 

Figure  7.2:  Abstract  Escape  Semantic  Functions  for  Lazy  Evaluation 
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The  definitions  of  the  abstract  escape  semantic  functions  are  given  in  Figure  7.2.  Note  that 
the  definition  of  the  abstract  escape  semantic  function  Oe  for  lambda  expressions  of  the 
form  lambda(*).e  treats  free  identifiers  differently  according  to  their  evaluation  status. 

Global  Lazy  Escape  Test 

We  describe  a  global  escape  test  for  lazy  functions.  Given  a  lazy  function  f  x  1X2  ■  ■  ■  xn  = 
bodyj  of  arity  n,  the  position  i  of  an  interesting  parameter,  an  abstract  escape  semantic 
environment  env0  mapping  a  transformed  version  of  /  to  an  element  of  D0,  the  global  lazy 
escape  test  function  GJ_escape?  determines  whether  the  ith  parameter  of  the  lazy  function 
/  could  possibly  escape  /  globally  or  not.  It  is  defined  as  follows: 

G  J_escape? (/,  i,  efiv0)  =  (0e[/'  x1  . . .  xnJ  ehv0[xi  ^ 

where  f  is  a  transformed  function  of  /, 

Vi  =  <M()-<WTi»> 
for  all  j  <  n  and  j  ^  i. 

y3  =  <0,A().<0,W™)>, 

and  Tj  is  the  type  of  the  ith  parameter  of  /.  Then,  from  the  result  of  the  global  lazy  escape 
test  function,  we  can  conclude  as  follows: 

•  If  GJ_escap e!(f,i,ehv0)  =  0  then  we  conclude  that  in  any  possible  application  of  a 
lazy  function  /  to  n  arguments,  the  ith  delayed  argument  does  not  escape  /. 

•  If  GJ_escape?(/,  i.  env0 )  =  1  then  it  means  that  the  ith  delayed  argument  could  escape 
/  in  some  possible  application  of  a  lazy  function  /  to  n. 

Local  Lazy  Escape  Test 

We  describe  a  local  escape  test  for  lazy  functions  in  a  particular  context.  Given  a  lazy 
function  f  x  1  x?  ...  xn  =  bodyj  of  arity  n  in  an  application  context  /  gj  ...  en,  the 
position  i  of  an  interesting  parameter,  and  an  abstract  escape  semantic  environment  ehv0 
mapping  a  transformed  version  of  /  and  the  free  identifiers  within  ei  through  en  to  elements 
of  D0 ,  the  local  lazy  escape  test  function  LJ_escape?  determines  whether  the  ith  parameter 
of  the  lazy  function  /  could  escape  /  in  the  evaluation  of  /  e\  . . .  en.  It  is  defined  as 
follows: 
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LJ_escape?(/.  «.f  i, .  ..,en,env0)  =  {Oe{f  x1  . . .  xnJ  env0[xi  h->  (/;J)(1! 
where  /'  is  a  transformed  function  of  /, 

Vi  =  <l,A().<l,(Oe[e4]  ent70)(a))) 
and  for  all  j  <  n  and  j  ^f-  i. 

yj,  -  <0,  A().<0,(Oc[ej]  eno^j])). 

Then,  from  the  result  of  the  local  lazy  escape  test  function,  we  can  conclude  the  following: 

•  If  L J^escape? (/,  *,  e i, . . . ,  en,  env0)  =  0  then  we  conclude  that  the  ith  delayed  argument 
does  not  escape  /  in  the  particular  application  of  /  to  e\  through  e.n . 

•  If  LJ_escape?( /,  i,  ei, . . . ,  e„,  ehv0)  =  1  then  it  means  that  the  ith  delayed  argument 
could  escape  /  in  the  particular  application  of  /  to  ej  through  en. 


7.2.3  Reference  Escape  Analysis  for  Lazy  Evaluation 


The  abstract  reference  escape  semantic  domain  Dr  and  the  domain  Er  of  the  abstract 
reference  escape  environments  are  defined  as  follows: 


Dr  = 
Er  = 


p\int 
±J  r 

p\bool 
±J  r 

r 

p\r  list 
±Sr 


/*  Abstract  reference  escape  semantic  domain  */ 

Id  —*  Dr  /*  Domain  of  abstract  reference  escape  environments  * / 

=  Br  X  {err}  abstract  subdomain  for  integers 

=  Br  X  {err}  abstract  subdomain  for  booleans 

=  Br  X  ( D l1  —r  D}2)  abstract  subdomain  for  functions 

=  DJ.  abstract  subdomain  for  lists  of  typer  list 


We  now  introduce  the  abstract  reference  escape  semantic  functions  to  give  the  syntax  the 
reference  escape  meaning  as  follows: 

Rc  :  Con  —>  Dr  /*  Abstract  reference  escape  function  for  constants  */ 

Re  :  Exp  —  Er  Dr  /*  Abstract  reference  escape  function  for  expressions  */ 

Rpr  :  Program  —  Dr  /*  Abstract  reference  escape  function  for  programs  */ 

The  semantic  equations  for  the  abstract  reference  escape  semantic  functions  are  given  in 
Figure  7.3.  Note  that  the  definition  of  the  abstract  reference  escape  semantic  function  Re 
for  lambda  expressions  of  the  form  lambda(a’).e  treats  free  identifiers  differently  according 
to  their  evaluation  status. 
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Roll}}  =  ((0,0),  err) 

-Rc[c]  =  ((0,0),  err),  c  G  -1, 0, 1, true,  false} 

.Rcjni]/  =  _Lr  (The  bottom  element  of  Dr.) 
i^Jcons]  =  ((0,0),Xx.(x^,Xy.xUy)) 

£c[cars]  =  ((0,  0),  As.cuts(s)) 

Ecjcdr]  =  ((0,0),  As. a:) 

-Rc[null]  =  ((0,0),  As. ((0,0), err) 

Relc}envT  =  Rc{cj 

Re\x\envf  =  ehrr[s] 

Re\e i  +  fivr  =  ((0,  0),  err)  /*  same  for  e\  —  e2  and  e\  =  e2  */ 

Re\ if  e i  then  e2  else  e^\envr  =  {Re\e-[\envr)  U  (-Re^Jehr,.) 

Re[e02\envr  =  (  R,  l«jj'  «''v)(2)  ( R< 1'  2 1'  «''•>) 

-Re[lambda(s).e]e7i%  =  (K-,  Aj/.^e[e]enrr[s  j/]) 

where 

F  =  (0,  0)  U  {  |J  (f  hr,  |rj)(1))  U  (  jj  (Oe[  (z  [])  ]ehrr)(1)) 

z£]7 _ Jpeval  g^jpeval 

F  =  Set  of  free  identifiers  in  (lambda(s).e),  and 
jpeval  _  ge£  q£  £ree  identifiers  with  an  evaluated  status. 

Eejletrec  x\  =  e\\ . . .  xn  =  en;  in  e]ehrr  =  Re\e\ehv'r 

where  ehv'r  =  efivr[xi  i— >  Re\e-[\ehv'r , . . . ,  xn  -ffie[eK]ehr(,] 

i?pr[pr]  =  Re\pr\nullenvr 

Figure  7.3:  Abstract  Reference  Escape  Semantic  Functions  for  Lazy  Evaluation 
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Global  Lazy  Reference  Escape  Test 

Given  a  lazy  function  f  x  1X2  . . .  xn  =  bodyj  of  arity  n,  the  position  ( i .  j)  of  an  interesting 
occurrence  of  a  parameter,  and  an  abstract  reference  escape  semantic  environment  envr 
mapping  an  auxiliary  function  for  a  transformed  version  of  /  to  element  of  Dr ,  the  global  lazy 
reference  escape  test  function  G  J_refescape?  determines  whether  the  reference  associated 
with  the  jth  occurrence  of  the  ith  parameter  of  the  lazy  function  /  could  escape  /  globally 
It  is  defined  as  follows: 

GJ_refescape?(/,  i,  j,  ehz y)  = 

(Relf"  x1  ...  Xlo(1)  ...  Xn  ...  X  eflVrlf"  H-  /",  Xij  3/zi])(l)(l) 

where  f"  is  an  auxiliary  function  for  f  is  a  transformed  function  of  /, 
f"  =  Relf}envr, 

Vi..  <{  1  •  0)  :  '"M  )•<<  1  •  ())•  11  fi)): 
for  all  k  <  o(i )  and  k  7^  j, 

Uik  —  <(0,  0),  A().<<0,  0),  lTTi)}, 
and  for  all  1  <  m  <  o(  l)  and  /  7^  i. 
ylm  -  {{().()).  A(). {{().()).  H  '')). 

and  Tj  is  the  type  of  the  ith  parameter  of  /.  Then,  from  the  result  of  the  global  lazy  reference 
escape  test  function,  we  can  conclude  the  following: 

•  If  G  J_refescape? (/,  i.  j ,  cnvr)  =  0  then  we  can  conclude  that  in  any  possible  application 
of  a  lazy  function  /  to  n  arguments,  the  reference  associated  with  the  jth  occurrence 
of  the  ith  delayed  argument  does  not  escape  the  function  /. 

•  If  G  J_refescape?(/,  i,  j,  ehvr  )  =  1  then  it  means  that  in  some  possible  application  of 
a  lazy  function  /  to  n  arguments,  the  reference  associated  with  the  jth  occurrence  of 
the  ith  delayed  argument  could  escape  the  function  /. 

Local  Lazy  Reference  Escape  Test 

Given  a  lazy  function  f  x  1X2  ■  ■  ■  xn  =  bodyj  of  arity  n  in  an  application  /  ey  ...  en,  the 
position  (i.  j)  of  an  interesting  occurrence  of  a  parameter,  and  an  abstract  reference  escape 
semantic  environment  envr  mapping  an  auxiliary  function  for  a  transformed  version  of  / 
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and  the  free  identifiers  within  e\  through  en  to  elements  of  Dr ,  the  global  lazy  reference 
escape  test  function  LJ_refescape?  determines  whether  the  reference  associated  with  the  jth 
occurrence  of  the  ith  parameter  of  the  lazy  function  /  could  escape  /  in  the  evaluation  of 
f  e i  ...  en.  It  is  defined  as  follows: 

LJ_refescape?( /,  i,j,  ei, . . . ,  em  envr)  = 

{Relf  xx  ...  xlo(Vj  ...  xn  ...  xno{n)\  envr[f"  J",  xi}  ^  y*i]).(l)(i) 

where  f”  is  an  auxiliary  function  for  [' .  f  is  a  transformed  function  of  /, 

f"  =  Relfjenvr, 

Vij  =  «1,0),A( ).((!,  0),(AN]e^)(2))), 
for  all  k  <  o(i )  and  k  ^  j, 

Vik  =  «0,0),A().«0,0),(i?e[e4]e^r)(2))), 

and  for  all  1  <  m  <  o(l )  and  l  ^  i, 

Vim  =  «0,0),  A().<<0,0),(i2e[e/]ehur)(2))). 

Then,  from  the  result  of  the  local  lazy  reference  escape  test  function,  we  can  conclude  the 
following: 

•  If  LJ_refescape?(/,  i,  j,  ei, . . . ,  en,  envr)  =  0  then  we  conclude  that  the  reference  as¬ 
sociated  with  the  jth  occurrence  of  the  ith  delayed  argument  does  not  escape  /  in 
(/  e!  ...  en). 

•  If  LJ_refescape?(/,  i,  j,  ei, . . . ,  en,  ehvr )  =  1  then  it  means  that  the  reference  associated 
with  the  jth  occurrence  of  the  ith  delayed  argument  could  escape  /  in  (/  ei  ...  en ). 

7.2.4  Examples 

As  an  example,  consider  the  following  non-strict  (with  lazy  evaluation)  program: 

letrec  f  x  y  =  x+y; 

g  a  =  if  (a=0)  then  (f  a)  else  (f  3) ; 
h  c  d  =  g  (c+d) ; 

in  ... 

where  f ,  g,  h  :  int  int  — *■  int.  The  transformed  functions  f  ’ ,  g'  and  h’  for  f,  g  and  h, 
based  on  the  program  transformation  function  N,  are  defined  as  follows: 
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letrec  f’  x  y  =  (x  [] )  +  (y  []); 

g’  a  =  if  ((a  [] )  =0)  then  (f  ’  lambdaQ  .  (a  [])) 
else  (f’  lambdaQ  . 3) ; 
h’  c  d  =  g’  lambdaQ.  ((c  [] )  +  (d  [])); 

in  ... 

where  f  ’  ,  g’  ,  h’  :  (*  ini)  — *  (*  — ►  int )  — »■  (*  — »  ini)  and  *  denotes  the  type  of  a 
void  identifier  and  a  dummy  expression.  Note  that  the  occurrence  of  g’s  parameter  a  in  the 
expression  (f  ’  lambdaQ  .  (a  []  ))  has  an  evaluated  status. 


Lazy  Escape  Information 


The  definitions  of  the  abstract  lazy  escape  semantic  values  /',  g':  and  h!  of  f  ’ ,  g’ ,  and  h’ 
are  expressed  as  follows: 

/'  =  (0,  Aa.(a(1),  Ay.(0 ,err))) 

g'  =  (0,Aa.(/'2)  (0,A().a(0,err))U(/'2)  (0,  A().(0, err)))) 

=  (0,Aa.(/('2)  (0,  A().a  (0,  err))) 
ti  =  (0,  Ac.(cfl),  A d.g'{2)  ((c(1)  U  d(1)),  A(  ).(0,  err)))) 

Let  env0  =  [f  ’  f,  g’  g' ,  h’  i-*  h'\. 

To  find  the  global  escape  property  of  the  lazy  function  h,  we  apply  the  lazy  global  escape 
test  function  GJ_escape?  as  follows: 

G J jescape?(h,  1,  env0)  =  (Oojh’  c  djem/*,)^ 

=  0 


where 


env'0  =  env0[c 


(1,  A().(0,  d  i — >■  (0,  A().(0,  W-(—*«*)-»(.-*ii.t)))]j 


=  Aa.(a(1),  At/.a(1)  U  yyyerr)). 

Similarly, 

G  J  .escape?  (h,  2,  enva)  =  (00[h’  c  d]<  nv'0  )p  j 

=  0 

where 

env’o  =  env0[c  ^  (0,  A().(0,  *«*)—(— *««*))),  d  (1,  A().(0,  ^^M*^)))], 


_  Aa.(a|jj,  Xy.x^  U  yyyerr)). 
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Thus,  we  can  conclude  that  neither  the  first  parameter  c  nor  the  second  parameter  d  of  the 
function  h  escapes  h. 


Lazy  Reference  Escape  Information 

The  definitions  of  reference  escape  semantic  values  [' .  (f .  and  h!  of  f  ’ ,  g  ’ .  and  h  ’  are 
expressed  as  follows: 

/'  =  <(0,0),  Ax. Ay. ((0,0),  err))) 

9'  =  ((0,  0),  Ao.(/^2)  ((0,  0),  A().a  ((0,  0),  err))  U  (/^2)  ((0,  0),  A().((0, 0),  err)))) 

=  ((0,0),  A a.(/('2)  (afl),  A().a  ((0,  0),  err))) 

b!  =  ((0,0),  Ac.(c(1),  Xd.g'{2)  ((cfl)  U  d(1)),  A().((0, 0),  err)))) 

The  auxiliary  functions  f  ’  ’  .g’  ’  and  h’  ’  for  the  transformed  functions  f  ’ ,  g’  and  h  ’  are 
defined  as  follows: 

f”  x  y  =  (x  [])  +  (y  []); 

g’  al  a2  =  if  ((al  [] )  =0)  then  (f’  lambdaO .  (a2  [])) 
else  (f’  lambdaO  . 3) ; 
h’  c  d  =  g;  lambdaO.  ((c  □ )  +  (d  [])); 

Then,  the  definitions  of  reference  escape  semantic  values  f" .  tj" .  and  h"  of  f  ’  ’ ,  g'  ’ ,  and 
h’  ’  are  expressed  as  follows: 

f"  =  ((0, 0),  Aar.<as(1),  Ay  .((0,0),  err))) 

g"  =  ((0,  0),  Aal.(ol(1),  Ag2.(/'2)  (g2(1),  A(  ).a2(2)  ((0,  0),  err))) 

h"  =  ((0,  0),  Ac.(c(1),  A d.g'^  ((c(1)  U  d(1)),  A().((0, 0),  err)))) 

Let  envT  =  [f 5  i — >  /' ,  f 5  ’  i — >  /",  g  ’  i— >  g' ,  g  ’  ’  nr  g",h’  h',h’  ’  r*  h"]. 

To  find  the  global  reference  escape  property  of  the  non-strict  function  h,  we  apply  the 
non-strict  global  reference  escape  test  function  G J_refescape?  as  follows: 

GJ_refescape?(h,  1,  l,ehvr)  =  (.RellT  ’  c  d]em>V)(i)(i) 

=  0 

where 

env’r  -  envr[c  y*  ((1,  0),  A().<(1, 0),  w(*-*«*)-*(*-*«0)}., 
d  i  ?  ((0,  0),  A().((0,  0),  w(*-***)-(.-Mnt)))] 

Similarly, 
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GJ_refescape?  (h,  2, 1,  ehvr ) 


=  (Re[h>  ’  c  d]f  nr',. 

=  0 

where 

env'T  =  envT[c  ^  ((0,  0),  A().«0, 0), 

d  ^  ((1,  0),  A().«l,  0),  W(*^int)^(*->int)]) ] 

Thus,  we  can  conclude  that  neither  the  reference  associated  with  the  first  occurrence  of  the 
first  parameter  c  of  the  function  nor  the  reference  associated  with  the  first  occurrence  of 
the  second  parameter  d  of  the  function  h  escapes  h. 

7.3  Escapement  under  Evaluation  with  Strictness 

Strictness  information  about  parameters  of  a  lazy  function  can  be  used  for  improving  the 
lazy  evaluation  strategy  by  directly  evaluating  strict  arguments  before  they  are  passed 
to  the  function  body.  This  evaluation  strategy  can  be  considered  as  a  combination  of 
applicative-order  evaluation  (strict  semantics)  and  lazy  evaluation  (non-strict  semantics). 
The  escapement  property  under  this  evaluation  strategy  can  be  effected  by  transforming 
non-strict  programs  using  the  strictness  information  about  non-strict  functions.  We  assume 
that  with  individual  application  nodes  in  the  bodies  of  functions  strictness  information  is 
annotated  to  indicate  strict  applications  ([66]).  The  new  source-to-source  transformation 
function  M  of  type  Exp  — ►  Powerset(  Id)  —  Exp  for  non-strict  programs  with  strictness 
annotations  is  defined  in  Figure  7.4. 
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M[c]  Fid  =>  AQ.c 

Mfa]  F/d  =>  if  (a  G  Hd)  then  a  else  (a  []  ) 

M{e1  +  e2\FId  =>  (M[ei]  Fid)  +  (M[e2]  Fid) 

/*  same  for  strict  operators  like  (ej  —  62)  and  (ei  =  e2)  */ 
M|if  ei  then  e2  else  63]  Fid  =>■  if  (M[ei]  F/d) 

then  (  M[e2]  i  /d) 
else  (M[e3]  Fid) 

Fid  =>  if  ej  G  {  car,  cdr  }  /*  strict  operator  */ 

then  (M[ei]  F/d)  (M[e2]  Fid) 
elseif  (strict Mpplicationi)  /*  strict  application  */ 
then  (M[ei]  Fid)  (M[e2]  Fid) 
else  /*  non-strict  apphcation  */ 

(M[d]  Fid)  (A().M[e2]  Fid) 

M[lambda(a).e]  Fid  =>■  lambda(a).(M[e]  Fid) 

Mfletrec  xj  =  ei; . .  ,xn  =  e„;  in  e]  Fid  =>  letrec 

x1  =  M|ei]  ( Fid  U  {aj, . . a,,}); 


MP[pr]  M[pr]  0 


xn  =  M[e„]  (Fid  U  {al5 . . . ,  a„}); 

in 

M[ei]  (Fid  U  {xi, a„}) 


Figure  7.4:  Non-strict  Program  Transformation  with  Strictness  Information 
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Chapter  8 


Storage  Management 
Optimizations 


The  escape  information  that  is  inferred  at  compile-time  from  the  semantic  analyses  which 
have  been  described  in  preceding  chapters,  including  escape  analysis,  refined  escape  anal¬ 
ysis,  reference  escape  analysis,  and  order-of-demand  analysis,  allows  a  variety  of  storage 
management  optimizations  in  functional  language  implementations. 

In  this  chapter,  we  propose  a  variety  of  optimization  techniques,  based  on  statically 
inferred  escape  information,  to  reduce  the  storage  management  overhead  in  functional  lan¬ 
guage  implementation,  including  stack  allocation,  explicit  reclamation,  in-place  reuse  of 
garbage  cells,  reference  counting  elimination,  block  allocation/reclamation,  and  improving 
generational  garbage  collection. 

8.1  Stack  Allocation 

The  need  for  heap  allocation  of  objects,  such  as  arguments  and  locally  defined  objects 
within  a  higher-order  function,  arises  because  they  may  outlive  a  call  to  that  function, 
that  is,  the  environment  in  which  they  were  created.  Thus,  they  cannot  be  deallocated 
when  the  environment  is  left  and  its  bindings  are  deallocated.  For  example,  when  a  partial 
application  or  explicit  lambda  expression  is  evaluated  to  produce  a  closure,  the  storage  must 
be  allocated  and  the  values  must  be  moved  into  the  closure.  Generally,  closures  (the  code 
pointer  and  environment)  need  to  be  stored  in  the  heap  at  run-time  and  reclaimed  by  some 
garbage  collection  process. 

On  most  current  systems,  the  stack  allocation  and  deallocation  is  usually  more  efficient 
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both  in  space  and  in  time  than  the  heap  allocation  and  garbage-collected  reclamation,  al¬ 
though  the  overhead  of  a  garbage  collection  can  be  quite  small  with  a  sufficiently  large 
amount  of  physical  memory  and  a  sophisticated  garbage  collection  strategy  [5].  The  moti¬ 
vation  is  to  avoid  allocation  of  objects  in  the  heap  and  instead  to  allocate  them  in  the  stack. 
Objects  that  would  otherwise  be  allocated  in  the  heap  and  then  reclaimed  using  garbage 
collection  are  allocated  in  stack-like  storage  and  cheaply  reclaimed  without  invoking  garbage 
collection.  Optimizations  that  convert  heap  allocations  into  stack-like  storage  allocations 
are  expected  to  save  significant  time.  Converting  heap  allocation  to  stack  allocation  may 
also  permit  further  optimizations. 

Escape  information  about  parameters  of  a  strict  function  that  is  inferred  through  the 
(refined)  escape  analysis  can  be  used  for  the  stack  allocation  optimization.  Consider  any 
expression  of  the  form  of 

( J  ^  1  ■  ■  -  '  ^  n  ) 

where  /  is  a  function  with  n  parameters,  and  each  e4-,  1  <  i  <  n,  is  any  possible  expression. 
Let  e4  be  an  expression  whose  evaluation  requires  to  storage  allocation.  The  storage  for  the 
value  of  generally  needs  to  be  allocated  from  a  heap,  because  the  lifetime  of  e4  cannot  be 
predicted.  Based  on  the  global  escape  information  about  the  parameters  of  /,  more  efficient 
storage  allocation  can  safely  be  done  for  e4  as  follows: 

•  If  the  ith  parameter  of  /  does  not  escape  /  globally  then  allocate  the  storage  for  e  in 
the  stack  where  the  activation  record  for  /  resides,  else  allocate  the  storage  for  e  in 
the  heap. 

•  If  the  value  of  e4  is  a  constant  list  and  the  top  j  spines  of  the  ith  parameter  of  /  does 
not  escape  /  globally  then  allocate  the  storage  for  cells  at  the  top  j  spines  in  the 
stack  where  the  activation  record  for  /  resides,  and  allocate  the  storage  for  cells  at 
the  remaining  spines  in  the  heap. 

Consider  a  particular  subexpression  of 

if  ...  Ci  ...  en ) 

where  /  is  a  function  with  n  parameters.  Similarly,  the  local  escape  information  of  param¬ 
eters  of  /  in  (/  j§|  . . .  e4-  . . .  en)  can  be  used  for  more  efficient  storage  allocation  for  e4  as 
follows: 
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•  If  the  ith  parameter  of  /  does  not  escape  /  in  the  particular  application  (/  e\  ...  ej  ...  en) 
then  allocate  the  storage  for  e,  in  the  stack  where  the  activation  record  for  /  resides, 
else  allocate  the  storage  for  et  in  the  heap. 

•  If  the  value  of  e,  is  a  constant  hst  and  the  top  j  spines  of  the  ith  parameter  of  /  does 
not  escape  /  in  (/  ej  ...  e,  ...  en)  then  allocate  the  storage  for  cells  at  the  top  j 
spines  in  the  stack  where  the  activation  record  for  /  resides,  and  allocate  the  storage 
for  cells  at  the  remaining  spines  in  the  heap. 

As  an  example,  consider  the  program  given  in  Chapter  2  as  follows: 

letrec  g  a  b  =  if  (a  <  b)  then  0  else  a; 

h  c  d  =  if  (c  <  d)  then  d  else  0; 

map  f  1  =  if  (null  1)  then  nil 

else  cons  (f  (car  1))  (map  f  (cdr  1)); 

in  ...  (map  (g  3)  [1,3,5])  ...  (map  (h  3)  [1,3,5])  ... 

From  the  global  escape  analysis,  we  know  that  the  first  parameter  f  of  the  function  map  can 
never  escape  map  globally.  Thus,  in  any  subexpression  of  (map  e\  €2)  where  the  evaluation 
of  ei  requires  storage  allocation,  that  storage  for  ej  can  safely  be  allocated  in  the  stack  in 
which  the  activation  record  for  map  resides.  So,  the  storage  for  the  closures  representing  (g 
3)  and  (h  3)  can  be  allocated  in  the  stack  instead  of  the  heap. 

Even  though  we  cannot  conclude  from  the  global  escape  analysis  that  the  second  pa¬ 
rameter  1  of  the  function  map  does  not  escape  map  globally,  the  local  escape  analysis  tells  us 
that  the  second  parameter  1  of  the  function  map  does  not  escape  map  locally  in  (map  (g  3) 
[1,3,5]),  while  the  second  parameter  1  of  the  function  map  does  escape  map  locally  in  (map 
(h  3)  [1,3,5]).  Thus,  the  storage  for  the  cons  cells  of  [1,3,5]  in  (map  (g  3)  [1,3,5]) 
can  also  be  allocated  in  the  stack  instead  of  allocating  in  the  heap. 

The  global  refined  escape  analysis  tells  us  more  refined  escape  information  about  the 
second  parameter  1  of  map,  i.e.  the  top  spine  of  1  does  not  escape  map  globally.  Thus,  the 
storage  for  the  cons  cells  of  [1,3,5]  in  (map  (h  3)  [1,3,5])  can  also  be  allocated  in  the 
stack  instead  of  the  heap. 

Escape  information  about  the  parameters  of  a  non-strict  (lazy)  function  that  is  inferred 
through  the  escape  analysis  can  be  used  for  the  stack  allocation  optimization.  Consider  any 
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expression  of  the  form  of 

(  f  1  ■  ■  ■  ^ n  ) 

where  /  is  a  lazy  function  with  n  parameters,  and  each  e;,  1  <  i  <  n.  is  any  possible 
expression.  Each  argument  e;  to  /  requires  storage  allocation  for  representing  its  delayed 
evaluation  such  as  a  thunk  in  the  normal-order  evaluation  model  or  a  self-modifying  thunk 
in  the  lazy  evaluation  model.  Generally,  the  storage  for  each  ej  needs  to  be  allocated  in 
a  heap.  Based  on  the  global  escape  information  about  the  parameters  of  /,  more  efficient 
storage  allocation  can  safely  be  performed  for  the  thunk  of  each  e4-  as  follows: 

•  If  the  ith  parameter  of  /  does  not  escape  /  globally  then  allocate  the  storage  for  the 
thunk  of  e4  in  the  stack  where  the  activation  record  for  /  resides,  else  allocate  the 
storage  for  the  thunk  of  et  in  the  heap. 

Similarly,  the  local  escape  information  about  the  parameters  of  /  in  (/  e\  ...  e;  ...  en ) 
can  be  used  for  more  efficient  storage  allocation  for  the  thunk  of  each  e;  as  follows: 

•  If  the  ith  parameter  of  /  does  not  escape  /  in  (/  ...  e;  ...  en)  then  allocate  the 

storage  for  the  thunk  of  et  in  the  stack  where  the  activation  record  for  /  resides,  else 
allocate  the  storage  for  the  thunk  of  e ;  in  the  heap. 

As  an  example,  consider  the  following  lazy  program  from  Chapter  7: 

letrec  f  x  y  =  x+y; 

g  a  =  if  (a=0)  then  (f  a)  else  (f  3) ; 
h  c  d  =  g  (c+d) ; 
in  ...  h  (f  1  2)  (f  3  4)  .  .  . 

From  the  global  escape  analysis,  we  know  that  neither  the  first  parameter  c  nor  the  second 
parameter  d  of  the  function  h  escapes  h.  Thus,  in  any  subexpression  of  (h  e\  e2),  the  storage 
for  the  thunks  for  e\  and  e2  can  safely  be  allocated  in  the  stack  where  the  activation  record 
map  resides.  So,  the  self- modifying  thunks  for  both  (f  1  2)  and  (f  3  4)  in  h  (f  1  2)  (f 
3  4)  could  be  allocated  in  the  stack  where  the  activation  record  for  h  resides. 

Safety  Issue 

From  a  practical  point  of  view,  however,  there  are  safety  issues  in  the  application  of  storage 
allocation  optimization,  i.e.  unrestricted  application  of  the  stack  allocation  optimization 
may  be  unsafe  in  the  sense  that  it  can  convert  programs  that  run  well  into  programs  that 
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fail  (due  to  stack  overflow).  The  safety  condition  is  that  the  stack  allocation  optimization 
should  not  convert  a  program  that  runs  robustly  into  one  that  does  not  ([20],  [21]). 

8.2  Explicit  Reclamation 

When  heap-allocated  objects  are  no  longer  needed,  they  can  often  be  reclaimed  into  a  free 
storage  list  explicitly  by  the  program  without  invoking  the  garbage  collection.  This  is  done 
by  identifying  at  compile  time  where  run-time  storage  management  decisions  can  be  made, 

1. e.  the  places  in  a  program  where  storage  can  safely  be  collected.  When  we  can  predict  at 
compile  time  when  cells  will  become  garbage,  we  can  embed  into  the  executable  program 
additional  operations  which  immediately  link  the  garbage  cells  to  the  available  free  list. 
Thus,  we  can  avoid  some  of  the  expensive  operations  usually  used  to  detect  garbage  at  run 
time. 

Detecting  Sharing  using  Escape  Information 

Sharing  information  about  cells  can  be  determined  using  the  escape  information. 

Theorem  8.1  (Sharing  Information)  Let  f  be  a  function  which  takes  n  arguments  such 
that  di  is  the  number  of  spines  of  the  ith  parameter  of  f  for  i  =  1 . .  .n,  and  let  f  return  a 
list  with  dj  spines.  If  esci  be  the  number  of  escaping  spines  of  the  ith  parameter  of  f  for 
i  =  1 . .  .n  (statically  inferred  by  escape  analysis <),  then 

1.  all  cells  in  the  top  (d j  —  max{min{esc i,  (di  —  Mi)}, . . . ,  min{escn,  ( dn  —  un)}})  spines 
of  the  result  of  (f  e i . . .  e„)  are  unshared  for  arguments  Cj, . . .  ,en  such  that  u {  is  the 
number  of  unshared  spines  of  e^. 

2.  all  cells  in  the  top  (dj  —  max{esci, . . . ,  escn } )  spines  of  the  result  of  (f  e i  . . .  en),  for 
any  set  of  arguments  e%, . . .  .en,  are  unshared. 

Proof  :  1.  The  number  of  spines  of  e.l  that  are  shared  is  ( dt  —  ut ) .  The  number  of 
shared  spines  of  e4-  that  could  escape  /  is  min{esci ,  (d4-  —  Mi)}.  In  the  result  of  (/  ei . . . (-,.). 
the  bottom  max{min{esci,(di  —  m4)}}  spines  will  be  shared.  Thus,  all  cells  in  the  top 
(dj  —  max{min{esci,  (di  —  Mi)}, . . . ,min{escn,(dn  —  m„)}})  spines  of  the  result  are  not 
shared. 

2.  Since  we  consider  any  set  of  arguments  ei, . .  ,.en,  and  we  have  no  sharing  information 
of  e^,  we  assume  that  Mi  =  0  as  the  worst-case.  Then,  min{esci,  (di  —  0)}  =  esc{  because 
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esci  <  di .  Thus,  all  cells  at  top  ( d j  —  max{min{esc\, . . .  ,escn}})  spines  of  the  result  are 
not  shared.  □ 

As  an  example,  consider  the  program  given  in  Chapter  3  as  follows: 

letrec  ps  x  =  if  (null  x)  then  nil 

else  letrec  y  =  split  (car  x)  (cdr  x)  nil  nil; 
in  append  (ps  (car  y)) 

(cons  (car  x)  (ps  (car  (cdr  y)))); 

split  p  x  1  h  =  if  (null  x)  then  (cons  1  (cons  h  nil)) 
elseif  (car  x)<p  then 

split  p  (cdr  x)  (cons  (car  x)  1)  h 
else  split  p  (cdr  x)  1  (cons  (car  x)  h) ; 

append  x  y  =  if  (null  x)  then  y 

else  cons  (car  x)  (append  (cdr  x)  y) ; 

in  ps  [5,2,7, 1 ,3,4] 

The  function  ps  takes  a  list  with  one  spine  as  its  argument,  and  returns  a  list  with  one  spine. 
From  the  global  refined  escape  analysis,  we  know  that  no  spine  of  the  argument  escapes 
ps  globally.  Thus,  for  any  expression  (ps  e)  where  e  is  a  list  with  one  spine,  we  conclude 
that  the  top  spine  of  the  result  list  of  (ps  e)  is  not  shared.  The  function  split  takes  four 
arguments  p,  x,  1  and  h  whose  type  are  int,  int  list,  int  list  and  int  list ,  respectively, 
and  returns  a  list  with  two  spines.  From  the  global  refined  escape  analysis,  we  know  that 
none  of  the  first  parameter  p,  all  but  the  top  spine  of  the  second  parameter  x,  and  all  of 
the  third  and  fourth  parameters  1  and  h  escape  split  globally.  Thus,  we  conclude  that, 
for  any  subexpression  of  (split  ei  e2  e%  64)  where  each  is  any  possible  expression,  the 
top  spine  of  the  result  list  of  (split  e\  e2  e 3  €4)  is  not  shared. 

We  can  detect  some  garbage  objects  at  compile-time  using  sharing  and  escape  informa¬ 
tion. 

Theorem  8.2  Consider  an  expression  ( /  ei, . . . ,  e;, . . . ,  e„),  where  f  is  a  function  of  arity 
n.  Then , 

1.  If  is  a  function  type  and  the  ith  parameter  of  f  does  not  escape  f,  then  the  storage 
for  representing  the  closure  of  ei  is  garbage  after  the  execution  of  the  expression,  and 
thus  can  safely  be  reclaimed  after  the  execution  of  the  expression. 
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2.  Ifej  is  a  list  with  top  unshared  spines  and  the  bottom  esci  spines  of  the  ith  parameter 
with  d{  spines  escape  f,  then  all  cells  at  the  top  TO-m{w;,(d;  —  esci )}  spines  of  e;  are 
garbage  after  the  execution  of  the  expression ,  and  thus  can  safely  be  reclaimed  after 
the  execution  of  the  expression. 

Proof  :  Since  the  number  of  unshared  spines  of  e;  is  ut .  all  cells  in  the  top  w;  spines  of  ct 
are  unshared  before  the  execution  of  /.  Since  the  bottom  esct  spines  of  e;  escape  /,  the  top 
( di  —  esci )  spines  of  e;  do  not  escape  /.  The  spines  of  e;  that  do  not  escape  /  and  are  not 
shared  will  be  inaccessible  at  the  end  of  execution  of  /.  Thus,  the  top  min{ui,  (d4-  —  esc;)} 
spines  of  e;  become  garbage  during  the  execution  of  the  body  of  /  and  are  garbage  after 
the  execution  of  /.  □ 

Escape  information  that  is  inferred  from  the  (refined)  escape  analysis  can  be  used  for 
the  explicit  reclamation  optimization.  Consider  any  subexpression  of  the  form  of 

(  /  ea  . . .  e4_i  (g  e\  . . .  e'm)  ei+1  . . .  e  j 

where  /  and  g  are  functions  with  arity  n  and  m,  respectively.  Let  the  result  of  (g  e} ...  e'm) 
be  a  heap- allocated  object.  Generally,  that  object  is  reclaimed  by  garbage  collection.  Using 
the  global  escape  information  about  the  parameters  of  /,  more  efficient  storage  reclamation 
can  safely  be  done  for  the  result  of  (g  e'x  . .  .e'm)  as  follows: 

•  When  the  ith  parameter  of  /  is  a  function  type  :  If  the  ith  parameter  of  /  does  not 
escape  /  globally  then  the  subexpression  can  safely  be  transformed  into 

RECLAIM^/  e1 . . .  e4_i  (g  e[  . . .  e'm)  e4+i  ...en) 
where  RECLAIM;  reclaims  the  ith  argument  of  /. 

•  When  the  ith  parameter  of  /  is  a  list  type  with  di  spines  :  If  the  bottom  esc;  spines 
of  the  ith  parameter  of  /  escapes  /  then  the  subexpression  can  safely  be  transformed 
into 


RECLAIM;  (/  ej  . .  .e4_!  (g  ej  ...e'J  e4+1  ...e„) 
where 

■s  =  min {(dt  —  max{esc'1 , . . . ,  esc'^f}),  (di  —  esc;)}, 

esc; ,  1  <  i  <  to,  is  the  number  of  bottom  spines  of  the  ith  parameter  of  g  that  escape 
</,  and  RECLAIM;  reclaims  all  cells  in  the  the  top  s  spines  of  the  ith  argument  of  /. 
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As  an  example,  consider  the  same  program  as  in  section  8.1.  From  the  global  rehned  escape 
analysis,  we  know  that  append  returns  all  of  its  second  argument  y,  and  all  but  the  top 
spine  of  the  first  argument  x.  We  also  know  that,  for  any  expression  (ps  e)  where  e  is  a  list 
with  one  spine,  the  top  spine  of  the  result  of  (ps  e)  is  unshared.  Thus,  the  definition  of  ps 
can  be  transformed  into  PS  as  follows: 

PS  x  =  if  (null  x)  then  nil 

else  letrec  y  =  split  (car  x)  (cdr  x)  nil  nil; 
in  RECLAIM<1,1>  append  (PS  (car  y)) 

(cons  (car  x)  (PS  (car  (cdr  y)))); 

where  RECLAIM<1,1>  reclaims  all  cells  in  the  top  spine  of  the  first  argument  of  append. 
Note  that,  from  the  global  escape  analysis,  we  know  that  the  top  spine  of  ps’s  parameter 
does  not  escape  from  ps,  only  some  elements  do.  So,  each  cell  of  the  top  spine  of  the  list 
ps  [5,2,7, 1 ,3,4]  could  be  allocated  in  the  activation  record  for  ps. 

8.3  In-place  Reuse 

When  heap- allocated  objects  are  no  longer  needed  and  other  objects  need  to  be  allocated, 
the  storage  can  be  reused  directly  by  the  program  without  new  allocation  and  without 
invoking  garbage  collection.  The  motivation  is  to  replace  the  allocation  of  new  cells  by 
direct  reuse  of  previously  deallocated  garbage  cells. 

Theorem  8.3  Consider  an  expression  (f  . . . ,  e;, . . . ,  en),  where  f  is  a  function  with 
n  parameters.  Then,  if  each  e;  is  a  list  with  its  top  Ui  spines  unshared,  and  the  bottom 
esci  spines  of  the  di  spines  of  the  ith  parameter  of  f  escape  f  then  all  cells  in  the  top 
min{ui,  (di  —  esc;)}  spines  of  e;  are  garbage  after  the  execution  of  the  expression,  and  thus 
can  safely  be  reused  during  the  execution  of  the  expression. 

Proof  :  Since  the  number  of  unshared  spines  of  e;  is  w;,  all  cells  at  top  w;  spines  of 
e;  are  unshared  before  the  execution  of  /.  Since  the  bottom  esc;  spines  of  e;  escape  /, 
the  top  (di  —  esc;)  spines  of  e;  do  not  escape  /.  The  spines  of  e;  that  do  not  escape  / 
and  are  not  shared  will  be  inaccessible  at  the  end  of  the  execution  of  /.  Thus,  the  top 
min{ui ,  (di  —  esc;)}  spines  of  e;  become  garbage  during  the  execution  of  the  body  of  /  and 
are  garbage  after  the  execution  of  /.  □ 

Escape  information  about  parameters  of  a  strict  function  that  is  inferred  by  the  (refined) 
escape  analysis  can  be  used  for  the  in-place  reuse  optimization.  Consider  an  expression  of 
the  form  of 
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(/  ei  .  .  .  ...  €n  ) 

where  /  is  a  function  with  n  parameters,  the  ith  parameter  of  /  is  a  list  type  with  d{  spines, 
and  there  occurs  some  cons  in  the  body  of  /.  Let  all  cons  cells  at  the  top  U{  spines  of  the 
result  of  be  unshared.  Generally,  each  cons  appearing  in  the  body  of  /  allocates  a  new 
cons  cell  in  the  heap,  and  such  cons  cells  are  reclaimed  by  garbage  collection.  Using  the  global 
escape  information  of  parameters  of  /,  more  efficient  storage  allocation  and  reclamation  can 
safely  be  performed  as  follows: 

•  If  the  bottom  esc{  spines  of  the  ith  parameter  of  /  escapes  /  globally  then  the  subex¬ 
pression  can  safely  be  transformed  into 

iff  e1  . . .  ei  ...en) 
where 

5  =  min{ui:  (di  —  esc;)}, 

and  ff  is  a  new  version  of  /  which  directly  reuses  cells  in  the  top  s  spines  of  the  ith 
argument  of  /  for  new  cells  needed  in  the  body  of  /. 

Consider  a  function  /  as  follows: 

f  x1  ...  xn  =  ...  (cons  ei  e2)  ... 

•  If  there  is  no  use  of  the  ith  parameter  xt  of  /  after  the  evaluation  of  the  subexpression 
(cons  e\  e2)  then  a  new  version  ff  of  /  which  uses  the  in-place  reuse  optimization 
can  be  defined  as  follows: 


ff  X!  ...  xn  =  ...  (DCONS  Xi  e1e2)  ... 

where  DCOIS  is  a  destructive  version  of  cons  defined  by 

DCONS  a  b  c  =  {p  :=  a; 

car(a)  :=  6; 
cdr(a)  :=  c; 
return(p)}. 

As  an  example,  consider  the  partition  sort  program  from  the  previous  section.  From  the 
global  refined  escape  analysis,  we  know  that  append  returns  all  of  its  second  argument  y, 
and  all  but  the  top  spine  of  the  first  argument  x.  The  top  spine  of  the  list  that  ps  returns  is 
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unshared.  We  also  know  that,  for  any  expression  (ps  e)  where  e  is  a  list  with  one  spine,  the 
top  spine  of  the  result  of  (ps  e)  is  unshared.  Thus,  the  definition  of  ps  can  be  transformed 
into  PS  as  follows: 

PS  x  =  if  (null  x)  then  nil 

else  letrec  y  =  split  (car  x)  (cdr  x)  nil  nil; 
in  APPEND  (PS  (car  y)) 

(cons  (car  x)  (PS  (car  (cdr  y)))); 

where  APPEND  is  a  version  of  append  in  which  cells  are  directly  reused.  It  is  defined  by 


APPEND  x  y  =  if  (null  x)  then  y 

else  DCONS  x  (car  x)  (APPEND  (cdr  x)  y) ; 

Furthermore,  if  we  know  that  the  top  spine  of  the  argument  of  ps  is  unshared,  then  the 
definition  of  ps  can  be  transformed  into  PS’  as  follows: 

PS’  x  =  if  (null  x)  then  nil 

else  letrec  y  =  split  (car  x)  (cdr  x)  nil  nil; 
in  APPEND  (PS’  (car  y)) 

(DCONS  x  (car  x)  (PS’  (car  (cdr  y)))); 

8.4  Reference  Counting  Elimination 

Reference  counting  is  a  storage  reclamation  method  in  which  each  object  contains  a  count, 
called  the  reference  count,  of  the  number  of  references  (pointers)  pointing  to  it.  When  an 
object  is  first  allocated,  its  reference  count  is  set  to  one.  The  reference  count  is  updated 
during  execution  as  follows:  Each  time  a  new  reference  to  an  object  is  created,  the  object’s 
reference  count  is  incremented  by  one.  Each  time  a  reference  to  an  object  is  destroyed, 
the  object’s  reference  count  is  decremented  by  one.  When  an  object’s  reference  count 
becomes  zero,  it  can  be  reclaimed  and  the  reference  count  of  each  object  that  it  points 
to  is  decremented.  Though  the  reference  counting  strategy  has  disadvantages,  such  as 
storage  fragmentation  and  the  inability  to  reclaim  cyclic  structures,  its  major  advantage  is 
that  storage  reclamation  occurs  incremently  throughout  program  execution;  storage  can  be 
reclaimed  as  soon  as  it  has  become  garbage.  It  is  also  especially  suitable  in  multiprocessor 
architectures  with  distributed  memory,  since  reference  counting  is  an  inherently  real-time 
and  localized  activity. 
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The  major  overheads  that  are  incurred  in  reference  counting  schemes  are  as  follows: 

•  Space  overhead  for  maintaining  a  reference  count  in  each  object. 

•  Time  and  code  overhead  for  updating  reference  counts  when  references  are  created  or 
destroyed. 

•  Communication  overhead  for  manipulating  a  remote  reference  and  for  synchronizing 
the  operations  on  reference  counts  in  distributed  memory  environments  ([57]). 

We  describe  a  method  for  reducing  the  time,  code,  and  communication  overhead  of  reference 
counting  in  both  uniprocessor  and  multiprocessor  environments  by  compile-time  program 
analysis.  Our  approach  is  based  on  the  observation  that  such  overheads  can  be  reduced  by 
avoiding  unnecessary  reference  count  updates  using  statically  inferred  information  about 
the  lifetime  of  each  reference.  The  lifetime  of  a  reference  to  an  object  is  the  period  from 
when  the  reference  is  created  until  its  last  use.  Suppose  0  is  an  object  that  is  active  at 
some  time  to  during  execution.  Since  this  object  is  active,  there  is  at  least  one  reference 
pointing  to  it.  If  its  reference  count  0rc  is  n  then  there  are  exactly  n  references  pointing  to 
it.  Suppose  A  is  one  of  those  references.  Now,  suppose  that  a  new  reference  B  to  the  object 
is  created.  The  current  reference  count  of  the  object  is  incremented,  i.e.  0rc  :=  Orc  +  1. 
At  some  later  time  tj ,  suppose  that  B  is  discarded.  Then,  the  current  reference  count  of 
the  object  is  decremented,  i.e.  Orc  :  =  0rc  —  1 . 

If  we  can  determine,  at  compile-time,  that  A  will  still  be  active  at  time  ti ,  then  no 
reference  count  operations  are  required  when  B  is  created  or  destroyed.  Since  the  reference 
count  of  0  always  remains  greater  than  or  equal  to  one  from  time  to  to  time  ti ,  0  will  not 
to  be  reclaimed  between  time  to  and  time  ti .  Thus,  the  reference  count  updating  operation 
for  the  reference  B  can  be  avoided.  This  avoidance  optimization  is  safe  because  any  object 
which  is  still  active  will  not  be  reclaimed. 

Reference  escape  information  that  is  inferred  from  the  reference  escape  analysis  can  be 
used  for  the  reference  counting  elimination  optimization.  Let  /  be  a  strict  or  lazy  function 
defined  as  follows: 


J  Xi  ...  Xn  —  ...  Xij  .  .  . 

where  xtJ  is  the  jth  occurrence  of  the  ith  parameter  x,t  in  the  body  of  /  such  that  it  causes 
the  creation  of  a  reference  to  the  ith  argument  of  /  during  the  evaluation  of  an  application 
of  /  to  n  arguments.  In  classic  reference  counting  scheme,  the  reference  count  of  the  ith 
argument  of  /  needs  to  be  updated  when  the  reference  associated  with  xtJ  is  created  and 
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destroyed.  Based  on  the  global  reference  escape  information  of  occurrences  of  the  parameters 
of  /,  more  efficient  reference  count  updating  can  safely  be  done  as  follows: 

•  If  Xij  does  not  reference-escape  /  globally  then  just  create  and  destroy  the  reference 
without  reference  count  updates  else  create  and  destroy  the  reference  with  reference 
count  updates 

Furthermore,  given  two  references  A  and  B  to  a  heap  allocated  object,  the  relative 
lifetimes  of  A  and  B  can  be  computed  by  determining  if  there  is  a  scope  from  which  one 
of  them  escapes  but  not  the  other.  If  so,  when  the  shorter-lived  reference  is  created  and 
destroyed,  no  reference  count  operations  are  necessary.  In  some  programs,  in  fact,  our 
analysis  can  determine  if  some  reference  R  to  an  object  outlives  all  others.  Thus,  the  object 
can  be  reclaimed  as  soon  as  R  is  destroyed.  No  other  reference  counting  operations  are 
needed.  Notice,  however,  that  it  may  not  be  possible  to  determine  lifetime  of  R  (if  it  is 
embedded  in  a  structure,  for  instance),  and  thus  of  the  object,  at  compile  time. 

As  an  example,  consider  the  program  given  in  Chapter  4: 

letrec  map  f  1  =  if  (null  1)  then  nil 

else  cons  (f  (car  1))  (map  f  (cdr  1)); 

sum  1  =  if  (null  1)  then  0 

else  (car  1)  +  sum  (cdr  1) ; 

addsum  x  y  =  cons  x  (cons  y  (cons 

(map  (lambda(z) .  (sum  Y)  +  z)  X)  nil)); 

in  ... 

From  the  reference  escape  analysis,  we  know  that  the  reference  associated  with  the  second 
occurrence  of  each  parameter  x  and  y  of  addsum  does  not  escape.  Thus,  updates  on  the 
reference  count  of  each  parameter  could  be  avoided  when  creating  and  deleting  the  reference. 
Consider  the  following  lazy  program  from  Chapter  7 : 

letrec  f  x  y  =  x+y; 

g  a  =  if  (a=0)  then  (f  a)  else  (f  3) ; 
h  c  d  =  g  (c+d) ; 

in  ... 

From  the  reference  escape  analysis,  we  know  that  neither  the  reference  associated  with  the 
first  occurrence  of  the  first  parameter  c  of  the  function  nor  the  reference  associated  with 
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the  first  occurrence  of  the  second  parameter  d  of  the  function  h  escapes  h.  Thus,  reference 
count  updatings  can  be  avoided  when  these  references  are  created  and  deleted. 


8.5  Block  Allocation/Reclamation 

In  this  scheme,  a  number  of  objects  are  allocated  together  in  a  contiguous  block  of  a  heap 
storage  and  the  whole  block  is  put  on  the  free  list,  rather  than  the  individual  objects.  This 
allows  reclamation  of  larger  segments  of  storage,  and  reduces  run-time  overhead  by  avoiding 
the  traversal  of  the  individual  objects  (in  mark-sweep  collection,  for  instance). 

Escape  information  about  the  parameters  of  a  strict  function  that  is  inferred  at  compile¬ 
time  through  the  (refined)  escape  analysis  can  be  used  for  the  block  allocation/reclamation 
optimization.  Consider  any  subexpression  of  the  form  of 

(«/"*- 1  •  •  •  G  •  •  ■  ) 

where  /  is  a  function  with  n  parameters,  and  each  e«,  1  <  *  <  n,  is  any  possible  expression. 
Let  et  be  an  expression  whose  evaluation  requires  the  allocation  of  a  number  of  storage 
cells.  Generally,  each  individual  cell  of  the  value  of  et  needs  to  be  allocated  in  a  different 
area  from  a  heap.  Based  on  the  global  escape  information  of  parameters  of  /,  more  efficient 
storage  allocation  can  safely  be  performed  for  tl  as  follows: 

•  If  the  top  j  spines  of  the  ith  parameter  of  /  does  not  escape  /  globally  then  allocate 
all  cells  in  the  top  j  spines  together  in  the  same  block  in  the  heap 

Consider  a  particular  expression 

(/ei  . . .  Cj  ...  cn ) 

where  /  is  a  function  with  n  parameters.  Similarly,  the  local  escape  information  about  the 
parameters  of  /  in  (/  ej  . . .  e8-  ...  en )  can  be  used  for  more  efficient  storage  allocation  for 
ei  as  follows: 

•  If  the  top  j  spines  of  the  ith  parameter  of  /  does  not  escape  /  in  (/  e\  . . .  ...  en) 

then  allocate  all  cells  at  the  top  j  spines  together  in  the  same  block  in  the  heap 

As  an  example,  consider  the  program  in  section  8.1.  From  the  escape  analysis,  we  know  that 
the  top  spine  ofps’s  parameter  does  not  escape  fromps,  only  some  elements  do.  Thus,  each 
cells  of  the  top  spine  of  the  list  ps  [5 ,2,7, 1 ,3 ,4]  could  be  allocated  in  the  same  block  in 
the  heap. 
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8.6  Improving  Generational  Garbage  Collection 


Generational  garbage  collection  groups  objects  into  areas  according  to  their  predicted  life¬ 
times,  and  collect  areas  independently  and  asynchronously. 

Escape  information  about  parameters  of  a  strict  function  that  is  inferred  at  compile-time 
through  the  (refined)  escape  analysis  can  be  used  for  improving  the  generational  garbage 
collection  schemes.  Consider  any  expression  of  the  form  of 

[  f  yj  ■  ■  ■  (  /  •  •  ■  cn ) 

where  /  is  a  function  with  n  parameters,  and  each  G,  1  <  *  <  n,  is  any  possible  expression. 
Let  e;  be  an  expression  whose  evaluation  requires  storage  for  the  result.  In  classic  gener¬ 
ational  garbage  collection,  the  storage  for  the  value  of  e8-  needs  to  be  allocated  in  a  new 
area  (the  youngest  generation)  in  a  heap.  Based  on  the  global  escape  information  about 
the  parameters  of  /,  more  efficient  selection  of  generations  can  safely  be  performed  for  e; 
as  follows: 

•  If  the  ith  parameter  of  /  does  not  escape  /  globally  then  allocate  the  storage  for  e; 
in  a  region  with  current  youngest  generation  else  allocate  the  storage  for  e;  in  some 
region  with  older  generations. 

•  If  the  value  of  e ;  is  a  list  and  the  top  j  spines  of  the  ith  parameter  of  /  does  not  escape 
/  globally  then  allocate  the  storage  for  cells  at  the  top  j  spines  in  a  region  with  the 
youngest  generation  and  allocate  the  storage  for  cells  in  the  remaining  spines  in  some 
region  with  older  generations. 

Consider  a  particular  expression 

Ci  .  .  .  ...  6n ) 

where  /  is  a  function  with  n  parameters.  The  local  escape  information  about  the  parameters 
of  /  in  (/  ei  . . .  e;  ...  en )  can  be  used  for  more  efficient  storage  allocation  for  e;  as  follows: 

•  If  the  ith  parameter  of  /  does  not  escape  /  in  (/  &i  ...  C{  ...  en )  then  allocate  the 
storage  for  e;  in  a  region  with  the  youngest  generation  else  allocate  the  storage  for  e; 
in  some  region  with  older  generations. 

•  If  the  value  of  e;  is  a  constant  list  and  the  top  j  spines  of  the  ith  parameter  of  /  does 
not  escape  /  in  (/  ej  ...  et  ...  en)  then  allocate  the  storage  for  cells  at  the  top  j 
spines  in  a  region  with  the  youngest  generation  and  allocate  the  storage  for  cells  in 
the  remaining  spines  in  some  region  with  older  generations. 
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Escape  information  about  the  parameters  of  a  non-strict  function  that  is  inferred  at 
compile-time  through  the  escape  analysis  can  be  used  for  improving  the  generational  garbage 
collection  scheme.  Consider  any  expression  of  the  form 

(/%  ■  ■  ■  (■/  •  •  •  ) 

where  /  is  a  lazy  function  with  n  parameters,  and  e;,  1  <  i  <  n,  is  any  possible  expres¬ 
sion.  Each  argument  et  to  /  requires  the  allocation  of  storage  for  representing  its  delayed 
evaluation,  such  as  a  thunk  in  the  normal-order  evaluation  model  or  a  self-modifying  thunk 
in  the  lazy  evaluation  model.  Generally,  the  storage  for  each  et  needs  to  be  allocated  from 
a  heap.  Based  on  the  global  escape  information  about  the  parameters  of  /,  more  efficient 
selection  of  the  generations  of  storage  for  e.(  can  be  done  as  follows: 

•  If  the  ith  parameter  of  /  does  not  escape  /  globally  then  allocate  the  storage  for  the 
thunk  for  et  in  a  region  with  the  current  youngest  generation  else  allocate  in  some 
region  with  older  generations. 

Similarly,  the  locale  scape  information  about  the  parameters  of  /  in  (  /  ty  . . .  e;  ...  en )  can 
be  used  for  more  efficient  storage  allocation  for  the  thunk  for  each  e;  in  (f  6%  . . .  e;  ...  en ) 
as  follows: 

•  If  the  ith  parameter  of  /  does  not  escape  /  locally  in  (/  ej  ...  e;  ...  en )  then 
allocate  the  storage  for  thunk  of  e;  in  a  region  with  the  current  youngest  generation 
else  allocate  in  some  region  with  older  generations. 
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Chapter  9 


Related  Work,  Conclusions,  and 
Future  Work 


In  this  chapter,  we  survey  some  previous  work  related  this  thesis,  summarize  the  contribu¬ 
tions  of  this  thesis,  and  suggest  some  further  research  in  this  area. 

9.1  Related  Work 

Escape  and  Lifetime  Information 

Brooks,  Gabriel,  and  Steele  [16]  described  a  simple  first-order  escape  analysis  for  numbers 
in  LISP,  but  did  not  extend  it  for  arbitrary  objects.  Orbit,  an  optimizing  compiler  for 
Scheme,  used  a  simple  first-order  escape  analysis  to  stack  allocate  closures  [42],  Hudak  and 
Kranz  [42]  used  a  simple  first-order  escape  analysis  of  a  non-strict  functional  language  for 
stack  allocation  of  self-modifying  thunks. 

There  have  been  a  number  of  papers  describing  analyses  for  optimizing  storage  of  lists 
and  other  structures.  Most  of  these  analyses  have  been  first-order  (i.e.  not  accounting  for 
higher-order  functions.)  R.uggieri  and  Murtagh  ([71],  [72])  described  a  lifetime  analysis  for 
a  language  with  side-effects  and  complex  data  structures,  but,  again,  it  is  first-order. 

Inoue,  Seki,  and  Yagi  [49]  described  an  analysis  for  functional  languages  to  detect, 
and  reclaim  run-time  garbage  cells  based  on  formal  language  theory  and  grammars.  They 
focused  only  on  the  explicit  reclamation  of  cons  cells.  It  is  unclear  if  this  approach  could  be 
extended  for  higher-order  languages.  Besides  being  higher-order,  the  escape  analysis  that 
we  describe  in  this  thesis  is  a  more  general  lifetime  analysis  that  can  be  applied  to  objects 
other  than  lists. 
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Jones  and  LeMetayer  [51]  described  an  algorithm,  based  on  forward  and  backward  anal¬ 
yses,  for  detecting  sharing  of  objects  in  first-order  functional  languages,  and  describe  a 
method  for  reusing  of  cells  based  on  the  sharing  analysis.  We  use  only  forward  analysis 
providing,  perhaps,  a  simpler  conceptual  framework. 

Chase,  Wegman,  and  Zadeck  [22]  described  a  first-order  analysis  for  LISP  that  constructs 
graphs  representing  possible  list  structures  and  analyzes  the  graphs  for  possible  storage 
optimizations.  Our  analysis,  in  contrast,  benefits  from  a  type  system  that  restricts  the 
ways  that  lists  can  be  created  and  that  restricts  the  kinds  of  sharing  that  can  occur  within 
a  list  (for  example,  one  cannot  write  cons(x,x).) 

Deutsch  [28]  presented  a  lifetime  and  sharing  analysis  for  higher-order  languages.  The 
analysis  consisted  of  defining  a  low-level  operational  model  for  a  higher-order  functional 
language,  translating  a  program  into  a  sequence  of  operations  in  this  model,  and  then 
performing  an  analysis  to  determine  the  lifetimes  of  dynamically  created  objects.  The 
approach  is  one  of  collecting  interpretation,  in  that  it  analyzes  a  whole  program  to  infer 
properties  of  program  points.  Our  approach  is  to  define  a  high-level  non-standard  semantics 
that  in  many  ways  is  similar  to  the  standard  semantics  and  captures  the  precise  escape 
behavior  caused  by  the  constructs  in  a  functional  language.  We  then  define  an  abstraction 
of  these  semantics  which  provides  less  precise  information  but  which  allows  the  analysis  to 
be  performed  at  compile  time.  The  advantage  of  our  analysis  lies  in  its  conceptual  simplicity 
and  less  computational  cost  (compared  to  a  collecting  interpretation). 

Deutsch  and  Bobrow  [29]  proposed  a  method  for  reducing  the  overhead  of  updating 
reference  counts  in  which  reference  counting  activities  are  deferred  by  being  stored  into  a 
hie  called  a  transaction  hie  instead  of  being  immediately  performed.  Reference  counts  are 
then  adjusted  at  suitable  intervals.  Barth  [9]  showed  that  this  particular  reference  count¬ 
ing  scheme  could  benefit  from  compile  time  optimization  by  generating  fewer  transactions 
(reference  counting  activities)  based  on  compile  time  analysis  of  first-order  programs. 

Using  the  idea  of  weighted  references,  i.e.  each  reference  carries  a  weight  such  that 
the  sum  of  the  weights  of  all  references  to  an  object  is  equal  to  the  reference  count  of  the 
object,  there  have  been  a  variety  of  works  [10,82],  in  which,  when  a  new  reference  is  created 
to  an  object,  no  access  to  the  object  is  needed.  Goldberg  [32]  presented  a  generation- 
based  approach  for  distributed  systems  that  also  avoids  reference  count  operations  when 
a  reference  is  created,  and  also  described  the  applicability  of  escape  information  among 
references  to  reference  counting  schemes,  but  did  not  present  the  analysis. 

In  the  garbage  collection  area,  using  the  lifetime  of  objects(not  statically  inferred ), 


181 


Lieberman  and  Hewitt  [58]  suggested  a  copying  garbage  collection  in  which  storage  is  di¬ 
vided  into  regions  according  to  ages.  Hudak  [39]  presented  a  semantic  model  for  describing 
the  number  of  active  pointers  to  objects  for  an  applicative-order  interpreter  of  a  first-order 
function  language,  and  a  variety  of  its  abstractions  based  on  abstract  and  collecting  inter¬ 
pretations. 

Strictness,  Evaluation  Order,  and  Evaluation  Status  Information 

Information  about  which  arguments  of  a  function  will  definitely  be  demanded,  called  strict¬ 
ness  information,  is  used  to  optimize  lazy  evaluation  by  converting  lazy  evaluation  into 
applicative-order  evaluation  and  thus  reducing  the  overhead  of  lazy  evaluation.  Informa¬ 
tion  about  the  order  of  evaluation  of  the  arguments  to  a  function  can  be  useful  for  a  number 
of  optimizations,  including  copy  elimination  [11,30,35]  and  process  scheduling  in  a  parallel 
system  [13].  Information  on  the  status  of  evaluation  of  arguments  when  they  are  demanded 
is  useful  for  eliminating  unnecessary  checking  [14], 

There  have  been  many  papers  published  in  the  field  of  strictness  analysis  for  languages 
with  higher-order  functions,  polymorphism,  and  non-flat  domains  (  [18],  [45],  [36],  [37],  [43], 
[1],  [80],  [81]),  but  these  do  not  provide  information  about  the  order  or  status  of  evaluation 
of  arguments.  Issues  of  order  of  evaluation  are  addressed  in  [41],  and  a  variety  of  models 
for  obtaining  order  of  evaluation  information  in  a  first-order  non-strict  functional  language 
without  non- flat  domains  are  described  in  [12],  However,  those  models  are  somewhat  com¬ 
plex  and  the  extension  to  higher-order  languages  is  not  clear. 

Bloss  [13]  proposed  a  path  analysis  which  provides  a  range  of  static  information  in¬ 
cluding  strictness,  evaluation-order,  and  evaluation-status  information  in  a  first-order  lazy 
functional  language.  The  analysis  consists  of  determining  the  set  of  all  possible  evaluation 
sequences  called  paths  and  extracting  interesting  information  from  the  set.  Since  the  size 
of  the  abstract  semantic  domain  is  very  large,  the  time  complexity  of  the  analysis  for  first- 
order  languages  is  significantly  higher  than  that  of  strictness  analysis.  Path  analysis  can 
also  be  extended  to  higher-order  languages  [11],  However,  the  complexity  becomes  even 
worse  in  the  case  of  higher-order  languages,  and  it  is  not  clear  how  to  extract  much  useful 
information  from  higher  order  path  analysis.  In  [35]  a  method,  similar  to  the  path  model, 
for  extracting  some  information  about  order  of  evaluation  in  a  higher-order  strict  functional 
language  was  presented. 

Draghicescu  and  Purushothaman  [30]  presented  a  compositional  analysis  for  obtaining 
at  compile-time  some  information  about  the  order  of  evaluation  of  variables  in  a  first-order 
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non-strict  functional  language  with  both  lazy  evaluation  and  other  evaluation  strategies 
using  strictness  information.  This  approach  is  based  on  strictness  information  and  achieves 
a  lower  complexity  than  path  analysis  by  analyzing  relations  between  parameters  instead 
of  computing  all  possible  paths  of  parameters.  Our  work  deals  with  higher-order  functional 
languages  and  uses  a  smaller  abstract  domain  and  thus  shows  much  lower  complexity. 

Polymorphic  Invariance 

Abramsky  [1]  extended  the  strictness  analysis  for  monomorphic  languages  to  polymorphic 
languages  based  on  the  notion  of  polymorphic  invariance.  This  implies  that  the  strictness 
property  derived  from  one  monomorphic  instance  of  a  polymorphic  function  applies  to  all 
possible  monomorphic  instances.  Hughes  [47]  proposed  a  method  for  extending  abstract  in¬ 
terpretation  to  first-order  polymorphic  functions  by  calculating  approximations  to  abstract 
functions  of  all  instances  from  the  abstract  function  of  the  simplest  monomorphic  instance. 
Abramsky  and  Jensen  [3]  showed  a  proof  of  the  polymorphic  invariance  of  strictness  analysis 
based  on  the  categorical  notions  of  relators  and  transformations. 

9.2  Summary 

One  of  the  major  overheads  that  incur  in  implementing  functional  languages  is  the  storage 
management  overhead  due  to  dynamic  allocation  and  automatic  reclamation  of  indefinite- 
extent  storage.  The  goal  of  this  thesis  was  to  compute  information  about  the  lifetime 
of  dynamically-allocated  objects  in  higher-order,  polymorphic,  (either  strict  or  non-strict) 
functional  languages  with  non-flat  domains,  through  semantics-based  compile-time  analyses 
of  high-level  source  programs,  and  to  use  such  statically  inferred  information  for  reducing 
the  storage  management  overhead  in  functional  language  implementations. 

In  a  higher-order  functional  language,  exact  information  about  the  lifetime  of  objects, 
such  as  arguments  and  local  objects  defined  within  a  function,  with  respect  to  the  lifetime 
of  the  activation  of  the  function  call  is  generally  unknown  at  compile-time.  Thus,  when 
storage  is  needed  to  be  allocated  for  such  object,  it  is  usually  allocated  from  a  heap  and  has 
to  be  reclaimed  using  some  kind  of  automatic  reclamation  methods.  Lifetime  information, 
if  inferred  at  compile-time,  can  be  useful  for  efficient  management  of  storage  allocated  for 
those  objects  at  run-time.  In  Chapter  2,  we  have  presented  a  method  for  computing  safe 
information  about  the  relative  lifetime  of  arguments  and  local  objects  defined  within  a 
function  with  respect  to  the  lifetime  of  an  activation  of  the  function  for  a  monomorphic, 
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strict,  higher-order  functional  language.  This  method  is  based  on  a  compile-time  semantic 
analysis  called  escape  analysis  which  provides  information  about  the  lifetimes  of  objects 
A  method  for  improving  the  precision  of  escape  information  is  also  presented  using  the 
position  information  of  objects  in  a  list  structure. 

For  structured  objects  such  as  lists  and  trees,  the  escape  information  that  is  obtainable 
through  the  escape  analysis  is  rather  coarse  because  it  does  not  specify  how  much  extent  of 
the  object  escapes  even  when  only  some  part  of  structured  object  escapes.  In  Chapter  3,  we 
have  developed  a  method  for  computing  more  refined  escape  information  for  a  monomorphic, 
strict,  higher-order  functional  language.  This  method  is  based  on  a  compile-time  semantic 
analysis  called  refined  escape  analysis  which  is  an  extension  of  the  escape  analysis  and 
indicates  how  much  of  an  object  outlives  the  activation  of  the  function  call. 

In  a  higher-order  functional  language,  exact  information  about  the  lifetime  of  a  dynam¬ 
ically  created  reference  to  a  heap- allocated  object  is  generally  unknown  at  compile-time. 
Such  information,  if  inferred  at  compile-time,  can  be  useful  for  improving  the  reference 
counting  scheme  for  both  uniprocessor  and  multiprocessor  environments.  In  Chapter  4, 
we  have  described  a  method  for  computing  at  compile-time  safe  information  about  the 
relative  lifetime  of  dynamically  created  references  to  objects.  This  method  is  based  on  a 
compile-time  semantic  analysis  called  reference  escape  analysis. 

In  lazy  evaluation,  arguments  to  a  function  are  not  evaluated  unless  and  until  their  values 
are  demanded,  and  are  evaluated  only  once  upon  the  first  demand.  Their  values  are  then 
saved  to  be  used  for  subsequent  demands,  thus  avoiding  reevaluation.  Exact  information 
about  the  strictness  of  arguments,  the  order  of  evaluation  among  the  arguments,  and  the 
evaluation  status  of  arguments  when  demanded  is  generally  unknown  at  compile-time.  If 
inferred  at  compile-time,  such  information  can  be  useful  for  a  number  of  optimizations  for 
lazy  evaluation.  In  Chapter  5,  we  have  presented  a  method  for  statically  inferring  a  range 
of  information  including  strictness,  evaluation-order,  and  evaluation-status  information  in 
a  monomorphic,  higher-order,  non-strict  (with  lazy  evaluation)  functional  language.  This 
method  is  based  on  a  compile-time  analysis  called  order-of-demand  analysis  which  provides 
safe  information  about  the  order  in  which  the  values  of  bound  variables  are  demanded. 

All  of  the  semantic  analysis  presented  in  the  preceding  chapters  have  dealt  with  a  higher- 
order  functional  language  with  monomorphic  type  system  in  which  every  expression  is  rigidly 
typed.  Most  modern  functional  languages  adopt  a  rich  polymorphic  type  system  which  is 
more  flexible.  In  Chapter  6,  we  have  described  a  method,  based  on  the  notion  of  polymorphic 
invariance,  for  applying  the  escape  analysis,  the  reference  escape  analysis,  and  the  order- 
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of-demand  analysis  for  a  monomorphic  language  to  a  polymorphic  language. 

In  Chapter  7,  we  have  extended  the  escape  analysis  and  the  reference  escape  analysis  for 
a  strict  language  to  a  non-strict  (either  with  normal-order  evaluation  or  with  lazy  evaluation) 
language.  Based  on  a  source-to-source  transformation  of  non-strict  programs,  we  have 
described  a  method  to  extend  the  escape  analysis  and  the  reference  escape  analysis  for  a 
strict  language  to  a  non-strict  language  with  normal-order  evaluation  using  the  analysis 
techniques  for  a  strict  language.  The  lazy  evaluation  model  is  identical  to  normal-order 
evaluation  model  in  the  standard  semantics,  but  not  in  its  operational  semantics.  We 
then  presented  the  escape  analysis  and  the  reference  escape  analysis  of  non-strict  functional 
languages  with  lazy  evaluation  based  on  the  evaluation  status  information  statically  inferred 
by  the  order-of-demand  analysis  presented  in  Chapter  5. 

Finally,  in  Chapter  8,  based  on  the  statically  inferred  escape  information,  we  proposed  a 
variety  of  optimization  techniques  to  reduce  the  storage  management  overheads  in  functional 
language  implementations.  These  include  stack  allocation,  explicit  reclamation,  in-place 
reuse  of  garbage  cells,  reference  counting  elimination,  block  allocation/reclamation,  and 
improving  generational  garbage  collection. 

9.3  Future  Work 

We  would  like  to  observe  how  a  combination  of  these  analyses  and  optimizations  described 
in  this  thesis  work  when  they  are  implemented  in  real  compilers.  Future  work  includes 
extensions  of  escape  analyses  to  user-defined  types  (e.g.  trees,  etc.)  and  investigations  of 
more  efficient  algorithms  for  finding  fixpoints  or  of  using  a  type  system.  Effective  extension 
of  the  order-of-demand  analysis  to  functional  languages  with  lists  and  investigation  of  its 
applications  for  optimizations  in  lazy  evaluation  would  be  useful. 

For  practical  purpose,  it  will  be  worth  investigating  a  method  for  determining  at  compile¬ 
time  whether  the  stack  allocation  optimization  is  safe  in  the  sense  that  such  optimization 
does  not  convert  a  program  that  runs  robustly  into  one  that  does  not. 

It  might  also  be  fruitful  to  develop  other  semantic  analyses  for  higher-order  functional 
languages  based  on  the  framework  which  is  used  in  the  semantic  analyses  presented  in  this 
thesis. 
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